I'm not sure how enthusiastic I am about replacing my downstream Clang -fsanitize=local-init option with the upstream -ftrivial-auto-var-init=zero -enable-trivial-auto-var-init-zero-knowing-it-will-be-removed-from-clang. Yes, that's literally what you need to pass to enable this.
Conversation
Replying to
Yeah that’s the compromise approach which allowed it to go in at all… wants to get rid of it as well 🙂
IMO we need to show perf of 0 versus pattern can’t be bridged, so 0 is there to stay.
1
1
I'm not using zero for performance. I explain the choice in github.com/GrapheneOS/har as "Zero-based filling has the least chance of uncovering latent bugs, but also the best chance of mitigating vulnerabilities.". Uncovering bugs also isn't necessarily good for this use case.
I understand, but the discussion was around performance. If we want to keep zero, performance is how it’ll happen.
Or, empirical data that zero is better.
1
Isn't using it for hardening software in production a valid use case? I would be using zero filling even if the CPU performed worst for zero filling. Using a different value gets complicated because it ideally creates pointers to protected memory and far away from anything valid.
1
Show replies