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.
2
2
8
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.
I don't have any backlog of issues uncovered by the compiler-based filling on initialization. However, there are still a bunch of issues uncovered by either pattern filling on allocation or pattern filling on free with malloc. Most of these are in Qualcomm's proprietary code.
2
1
If you want to hit a bunch of issues, enable non-zero pattern filling on free for malloc and open up the camera app on the Pixel 3 or Pixel 3a. There are a bunch of use-after-free bugs. Zero filling uncovers a few, but non-zero uncovers many more and it often doesn't just crash.
2