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
Replying to
A few folks like and would also like to remove that silly extra flag. I think the performance argument can be made and will convince the LLVM community, without having to touch the landmine that security / compat seems to be 😕
I’ll happily help!
1
6
Performance was the only way I saw to convince folks that zero was useful: I’m sure it yield better performance.
I also agree with security concerns, with some caveats (patterns easier to detect…), but know this is contentious and folks are worried about language semantics 🤷♂️
2
We turned on pattern initialization so that we will actually find the bugs, but zero initialization would have probably have been less stressful on a personal level.
1
Pattern is nice because of you see it in a crash log then you kinda have a smoking gun.
2
2
Pattern initialization is great for debug builds. We've encountered multiple real world bugs in the Android Open Source Project and device support code where non-zero turns an inert bug into a potentially exploitable vulnerability. It's often not caught by running test suites.
I'd need to go through our historical bug reports. Unfortunately, Google doesn't link to the commit fixing the issue in the bug report (only in the security bulletin) and they don't reference the reporter in the commit (even if it's based on your patch) so it's a pain to search.
1
1
Show replies
Got any patches or bug reports for me? I work on AOSP, and while we did fix everything we found in aosp/master, perhaps there's still more lurking.
1
We've historically reported a bunch of these bugs to Google and Qualcomm, often through other developers because we lacked the time to follow up on each of our discoveries. I've also submitted patches to various projects myself when I had time. Most of these are already fixed.
1
1
Show replies