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.
Conversation
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.
1
1
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.
There are a bunch of issues in CamX and I don't know if my attempts to get them to deal with it is going anywhere. They assorted use-after-frees and uninitialized data usage with the stack and heap. I don't know why their camera code is always such a mess. Always the worst...
1
1
We only had one bad experience with an actual bug report to Google, where Google closed it WONTFIX so we just submitted a patch and then they wouldn't pay a bounty even though they ended up agreeing that it was a critical RCE bug in the Bluetooth stack since we'd made it public.
1
1
Show replies