Saagar Jha

(replying to Saagar Jha)
In many cases people will use it to avoid diagnosing real problems! If your code works with dates that doesn’t mean you can point at that part and say “oh this is probably broken because date math is hard” when something behaves in a way you didn’t expect

Saagar Jha

(replying to Saagar Jha)
When working in security I cannot just point at some code and say “this has undefined behavior therefore it is exploitable”. Even though compiler authors will generally tell you otherwise (mostly out of frustration) you can build useful security properties on top of UB
2 replies →
2 replies

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

Wyatt (🏳️‍⚧️♀?)

(replying to Saagar Jha)

@saagar OpenSSL did this iirc and debian broke it by trying to fix it. Maybe that was just uninitialized memory but I think that's a kind of undefined behavior.

Saagar Jha

(replying to Wyatt (🏳️‍⚧️♀?))
@wyatt8740 Trying to use undefined behavior in your code for intended functionality is generally a bad idea

Wyatt (🏳️‍⚧️♀?)

(replying to Saagar Jha)

@saagar It was essential to the design of OpenSSL because it increases the entropy of the seeds it generates

Saagar Jha

(replying to Wyatt (🏳️‍⚧️♀?))
@wyatt8740 Yes and this happened to be a bad idea :P

Wyatt (🏳️‍⚧️♀?)

(replying to Saagar Jha)

@saagar How was it a bad idea? It was a good idea; downstream idiots who didn't understand it purposefully broke the code thinking they were "fixing" it because they didn't understand the code and saw valgrind warn about it. That code is still in openssl.

Saagar Jha

(replying to Wyatt (🏳️‍⚧️♀?))
@wyatt8740 Using uninitialized memory as entropy is generally a bad idea. It doesn’t really help and it breaks tools that you would generally want to use to find real bugs. The “fix” was incorrect, of course, but not idiotic. FWIW, the code is gone now: https://github.com/openssl/openssl/commit/75e2c877650444fb829547bdb58d46eb1297bc1a#diff-7540ce8fd73afa23b44db37b090c9aa47f5c361f8f2bb5508be45555e9a1f6bbL191

Wyatt (🏳️‍⚧️♀?)

(replying to Saagar Jha)

@saagar how does drbg do it? Also if you lack the ability to think critically about the warnings a program is giving you when programming in general I think you're sort of cruising for a bruising. Deep understanding is always better than "waving a chicken at it until the warnings go away," or trusting software to be infallible.

Saagar Jha

(replying to Wyatt (🏳️‍⚧️♀?))
@wyatt8740 Not an expert but I think it just uses the ones you’d expect like system entropy and jitter

Saagar Jha

(replying to Saagar Jha)
Anyways the point I am making is that if “I don’t understand this” is in any part of your reasoning chain the final result needs to also be “I don’t understand this” not “things don’t work this way”

Wowfunhappy

(replying to Saagar Jha)

@saagar Playing devils's advocate a bit: it may be the case that you can increment a variable by using butterfly wings to deflect incoming cosmic rays, but I don't understand cosmic rays, and it's easier to write `i++`. Learning something you don't understand is often harder than just implementing something you do, so if you're trying to just get stuff done, saying "please use this solution which I know will work" isn't necessarily bad advice.

Wowfunhappy

(replying to Wowfunhappy)

@saagar Mind, I'm perfectly aware of all the ways this leads to madness. "Just use this library" leading to endless layers of abstraction, for example.

Saagar Jha

(replying to Wowfunhappy)
@Wowfunhappy To be clear I am not against abstraction or selecting what you want to learn here. I just caution against going “oh this thing is hard to understand therefore I will tell other people that they cannot work with it and must fear it”