GrapheneOS used to implement a local-init sanitizer for Clang to zero uninitialized variables in C and C++. In the development branch, this feature is once again globally enabled for Vanadium and the GrapheneOS kernel/userspace via Clang's new -ftrivial-auto-var-init=zero switch.
Conversation
Zero initialization is hidden behind -enable-trivial-auto-var-init-zero-knowing-it-will-be-removed-from-clang. We consider it part of the stable API regardless and depend on the feature. If it's removed, it will break compatibility with GrapheneOS and we'll just fork Clang again.
2
1
9
The existence of this switch is due to hostility by LLVM developers towards making existing C and C++ code safer. The desire for zeroing was misrepresented as being solely about performance. They're in denial about the unsafety of real world C and C++ code including within LLVM.
2
2
8
In the real world, C and C++ code makes pervasive use of uninitialized data and often depends on it being zeroed in practice. Initialization with a non-zero value is a dangerous backwards incompatible change. It regularly turns inert latent bugs into exploitable vulnerabilities.
Replying to
We've had years of experience working through these kinds of bugs when deploying these mitigations at scale. The problems are often subtle and not just hard to debug but difficult to detect in the first place. Zero is by far the least dangerous option for filling on init/free.
1
8
One of the arguments against the feature was the claim that it creates a language dialect. However, uninitialized usage is still a bug with -ftrivial-auto-var-init=zero and can still be detected by warnings, strict compiler checks or sanitizers. It's a code generation feature.
1
6
Programmers already wrote code depending on uninitialized data without this. Even without zero supported, programmers can incorrectly use the switch in an attempt to make uninitialized data usage well-defined. The performance argument is definitely valid, but not the only reason.
1
3
Read through the responses to lists.llvm.org/pipermail/cfe- (started April 21st) for some nice proof of the attitude, behavior and fallacies that I was talking about in this thread twitter.com/DanielMicay/st (April 9th). Not the only case where this anti-security attitude shows up either.
Quote Tweet
GrapheneOS used to implement a local-init sanitizer for Clang to zero uninitialized variables in C and C++. In the development branch, this feature is once again globally enabled for Vanadium and the GrapheneOS kernel/userspace via Clang's new -ftrivial-auto-var-init=zero switch.
Show this thread
1
3
Aside from issues like this, LLVM has serious correctness/robustness issues due to choosing to keep incorrect, incomplete implementations of optimizations enabled. Burden is placed on people who want it to be correct to fix them rather than people who want those optimizations...
1
2
The -enable-trivial-auto-var-init-zero-knowing-it-will-be-removed-from-clang switch reminds me a lot of llvm.sideeffect. Rather than disabling broken optimizations with near zero benefit until they're fixed with some obvious changes, they added a completely impractical hack...
Replying to
That sounds like a significant exaggeration. I agree zeroing yields increased safety in event of bugs, but no C code "depends on" it intentionally. No real world implementation except the clang option gives zeros; normally you get whatever was there last.
1
Replying to
When you're deploying it for an entire OS, enabling zeroing on init doesn't uncover any bugs in practice while enabling filling with a non-zero value uncovers a lot of them. For whatever reason lots of code has developed unintentional dependencies on uninit data often being zero.
2
1
Show replies