Wolf480pl

(replying to Saagar Jha)

@saagar
> you can build useful security properties on top of UB

until a compiler update comes

Saagar Jha

(replying to Wolf480pl)
@wolf480pl Not necessarily, see the replies to https://twitter.com/_saagarjha/status/1765843545112649985 for elaboration

Wolf480pl

(replying to Saagar Jha)

@saagar I can't see those :( I think twitter only shows them to logged-in users

Saagar Jha

(replying to Wolf480pl)
@wolf480pl tl;dr think trapping on (signed) overflow

Wolf480pl

(replying to Saagar Jha)

@saagar are we talking about C? is there a compiler flag that makes that happen?

Saagar Jha

(replying to Wolf480pl)
@wolf480pl -ftrapv in your favorite compiler

Wolf480pl

(replying to Saagar Jha)

@saagar well then the compiler is defining a behaviour that was previously undefined.

You're not guaranteed by C standard that overflows will trap, but you're guaranteed by the compiler that overflows will trap.
It's not UB on that compiler (and hopefully all future versions of that compiler, and maybe other compilers that have the same nonstandard feature). It's just non-portable code.

1/

1 replies →
1 replies

Saagar Jha

(replying to Wolf480pl)
@wolf480pl I don’t really want to interrupt you but the replies to that tweet basically mirror this conversation
1 replies →
1 replies

Wolf480pl

(replying to Saagar Jha)

@saagar I wish nitter was still alive

Saagar Jha

(replying to Wolf480pl)
@wolf480pl Well the other part is half the conversation is with a private account

Saagar Jha

(replying to Saagar Jha)
@wolf480pl I don’t like fundamentally disagree but my take there was “just because your compiler does something on UB does not make it any less UB” and “UB is precisely what gives the compiler leeway to trap”. But you are free to look at however you like

Wolf480pl

(replying to Wolf480pl)

@saagar

That being said I agree that teaching "UB is black box" is wrong. It's best to show an example how a seemingly innocent UB can cause an optimizing compiler to make assumptions and delete half of your code.
2/2

Saagar Jha

(replying to Wolf480pl)
@wolf480pl I bring this up mostly because people who have been trained that UB is only bad without truly understanding it make poor choices about what they think ought to be in the standard
1 replies →
1 replies

Wolf480pl

(replying to Saagar Jha)

@saagar IIRC there's also Implementation-Defined Behaviour which is less evil than UB because it requires the compiler to pick a behaviour upfront and be consistent with it.

Saagar Jha

(replying to Wolf480pl)
@wolf480pl Yeah my past discussion with people I think the viewpoint I have aligned with this one is that trapping should be a permitted implementation-defined behavior and for clearly broken constructs the only permissible behavior

Wolf480pl

(replying to Saagar Jha)

@saagar I don't know enough / haven't thought about it enough to have a definitive opinion on what should be done with UB.

But I kinda like zig's Debug / ReleaseSafe / ReleaseFast build modes.
Debug and ReleaseSafe trap on UB, ReleaseFast assumes no UB and optimizes as much as it can.

Saagar Jha

(replying to Saagar Jha)
@wolf480pl For what it’s worth I am in favor of abolishing undefined behavior by default but surprisingly few people agree with me on how to do that in a security-focused way

Wolf480pl

(replying to Saagar Jha)

@saagar well -O3 isn't a default :P

Saagar Jha

(replying to Wolf480pl)
@wolf480pl Despite my insistence that people who want portable assembler should use -O0, compilers can and do generate code assuming a lack of UB even at that optimization level
2 replies →
2 replies

Wolf480pl

(replying to Saagar Jha)

@saagar oof

lonjil

(replying to Saagar Jha)

@saagar @wolf480pl it's sort of impossible not to. Any transformation of code, no matter how simply, has to rely on the idea that the behavior of the code is the same before and after the transformation. And if there is no known behavior (because UB) you're outta luck.

Wolf480pl

(replying to lonjil)

@lonjil @saagar you (a compiler author) can still define the behaviour yourself, document it, then stick to it

lonjil

(replying to Wolf480pl)

@wolf480pl @saagar there's some low hanging fruit in C that's easy enough to define, but a lot of UB in C is very hard to define, at least on normal hardware.

(and you're probably not defining things differently at O0 and O3, I think?)

Wolf480pl

(replying to lonjil)

@lonjil @saagar no I actually mean define them only at O0 :P
Define them to do something dumb and potentially dangerous but predictable.
Bonus points if it matches most people's idea of a "a high-level assembly"

Wolf480pl

(replying to Wolf480pl)

@lonjil @saagar for example, have -O0 imply -fwrapv

Saagar Jha

(replying to Wolf480pl)
@wolf480pl @lonjil This is awful

Wolf480pl

(replying to Saagar Jha)

@saagar @lonjil but that's what you'd expect from a "high level assembly", right?

I'm not saying anyone should do that, just that there is a way to make O0 behave more like assembly

Saagar Jha

(replying to Wolf480pl)
@wolf480pl @lonjil I would generally want to divorce “do what I mean” from default debug builds tbh