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
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.
That's fine. I just wanted to make sure that people were actually fixing these and not just ignoring them. I appreciate your efforts in making everything more secure. I also learned some interesting things from your posts today, so thank you.
1
I've usually had decent experiences reporting issues to Google. The problem tends to be that we find too many issues and we lack the time to triage them and file reports. Dealing with Qualcomm is a lot more painful especially since a fair bit of their userspace code isn't open.
1
1
Show replies