Earlier quoted context omitted.
Not when computer security is concerned.
Security is a tradeoff. Perfect security is not using a computer.
Clang vs. Clang
401–405 of 405 posts
Re: Clang vs. Clang
#402Earlier quoted context omitted.
Yes, this is an example of UB leaving memory in a bad state. If you want an example of something that is not UB leaving memory in a bad state, here is some Go code: global := 7; func main () { go func() { global = 1000000; }() go func() { global = 10 }() fmt.Printf("gloabl is now %d") } The two concurrent writes may partially overlap, and global may have a value that is neither 7 nor 10 nor 1000000. The program's mem…
The C standard definitely has opinions on races
Re: Clang vs. Clang
#403Re: Clang vs. Clang
#404Earlier quoted context omitted.
I think this is actually a mistake by the author since the rant is mostly focused on implementation defined behavior, not undefined. The examples they give are all perfectly valid code. The specific bugs they're talking about seem to be compiler optimizations that replace bit twiddling arithmetic into branches, which isn't a safe optimization if the bit twiddling happens in a cryptographic context because it opens th…
The blog post does, at the very end, mention the thing you should actually do . You need a language where you can express what you actually meant, which in this case is "Perform this constant time operation". Having expressed what you meant, now everybody between you and the hardware can co-operate to potentially deliver that. So long as you write C (or C++) you're ruined, you cannot express what you meant, you are s…
Re: Clang vs. Clang
#405Earlier quoted context omitted.
I think this is actually a mistake by the author since the rant is mostly focused on implementation defined behavior, not undefined. The examples they give are all perfectly valid code. The specific bugs they're talking about seem to be compiler optimizations that replace bit twiddling arithmetic into branches, which isn't a safe optimization if the bit twiddling happens in a cryptographic context because it opens th…
The blog post does, at the very end, mention the thing you should actually do . You need a language where you can express what you actually meant, which in this case is "Perform this constant time operation". Having expressed what you meant, now everybody between you and the hardware can co-operate to potentially deliver that. So long as you write C (or C++) you're ruined, you cannot express what you meant, you are s…
This notion is not expressible in most (or almost all) high-level programming languages. Or, to put it another way: If you wrote C or C++ you never mean to say "perform this guaranteed-constant-time CPU operation" (ignoring asm instructions and hardware-aware builtins).