[cfe-dev] making -ftrivial-auto-var-init=zero a first-class option

[Alexander Potapenko via cfe-dev]

On Wed, Apr 22, 2020 at 5:43 AM JF Bastien <jfbastien at apple.com> wrote:
>
>
>
> On Apr 21, 2020, at 2:20 PM, Kees Cook <keescook at chromium.org> wrote:
>
> Hi,
>
> tl;dr: I'd like to revisit making -ftrivial-auto-var-init=zero an expressly
> supported option. To do this, I think we need to either entirely remove
> "-enable-trivial-auto-var-init-zero-knowing-it-will-be-removed-from-clang"
> or rename it to something more directly reflecting the issue, like
> "-enable-trivial-auto-var-init-zero-knowing-it-forks-the-language".
>
> This is currently open as https://bugs.llvm.org/show_bug.cgi?id=45497
>
> Here is the situation: -ftrivial-auto-var-init=pattern is great for
> debugging, but -ftrivial-auto-var-init=zero is needed for production
> systems for mainly two reasons, each of which I will try to express context
> for:
>
> 1) performance and size
>
> As measured by various Google folks across a few projects and in
> various places, there's a fairly significant performance impact of
> using pattern-init over zero-init. I can let other folks chime in
> with their exact numbers, but I can at least share some measurements
> Alexander Potapenko made with the Linux kernel (see "Performance costs"):
> https://clangbuiltlinux.github.io/CBL-meetup-2020-slides/glider/Fighting_uninitialized_memory_%40_CBL_Meetup_2020.pdf
> tl;dr: zero-init tended to be half the cost of pattern-init, though it
> varied based on workload, and binary size impact fell over 95% going
> from pattern-init to zero-init.
>
>
> The main reason folks were OK with me putting in zero init *at all* was to compare performance between 1) no init 2) zero init 3) pattern init, and *then* tune pattern init to the “floor” set by zero init. In other words: try to get to as low a cost as possible. I and other optimizer folks put significant efforts towards this, and we still are, but we’ve only done so for our binaries, and only on front-end / middle-end / ARM64. There’s still very low-lying fruit for pattern init on x86, and there’s more to be optimized on ARM64 and general middle-end. I’m therefore not sure we’re honoring the spirit of the agreement without putting in more optimization effort. To clarify: the performance got better, but we haven’t tried enough to declare “pattern init will definitely never get acceptably close to zero init”.
>
> At the same time, it’s pretty obvious that synthesizing zero will always be cheaper than synthesizing repeated bytes. The question we’ve still to answer is: does this matter?


It is true that pattern initialization has recently become a lot
faster. Thanks for all the efforts!

But one of the reasons to switch from pattern initialization to zero
initialization is that the former breaks buggy code that happened to
work previously.
I.e. along with making production code more secure (by mitigating
information leaks) we also introduce new crashes, making it less
stable.

> I’d like to see the remainder of the optimization work happen. It benefits generic code, not just pattern init. I don’t think it’s a mountain of work.



-- 
Alexander Potapenko
Software Engineer

Google Germany GmbH
Erika-Mann-Straße, 33
80636 München

Geschäftsführer: Paul Manicle, Halimah DeLaine Prado
Registergericht und -nummer: Hamburg, HRB 86891
Sitz der Gesellschaft: Hamburg