Date:   Wed, 31 Jul 2019 13:30:19 +0200
From:   Alexander Potapenko <glider@...gle.com>
To:     Linus Torvalds <torvalds@...ux-foundation.org>
Cc:     Kees Cook <keescook@...omium.org>,
        Linux List Kernel Mailing <linux-kernel@...r.kernel.org>,
        Arnd Bergmann <arnd@...db.de>
Subject: Re: [GIT PULL] meminit fix for v5.3-rc2

On Tue, Jul 30, 2019 at 9:54 PM Linus Torvalds
<torvalds@...ux-foundation.org> wrote:
>
> On Tue, Jul 30, 2019 at 6:53 AM Alexander Potapenko <glider@...gle.com> wrote:
> >
> > I wonder how hard it should be to make a zero-filling GCC plugin?
> > I'm not a big fan of hacking GCC, but it shouldn't differ much from
> > the existing GCC plugins that initialize locals.
>
> The thing is, as long as it's a plugin, I don't think we can rely on
> it. The gcc people will rightly just laugh at us if we were to report
> a bug with some kernel plugin.
>
> So I'd like the zeroing of local variables to be a native compiler
> option, so that we can (_eventually_ - these things take a long time)
> just start saying "ok, we simply consider stack variables to be always
> initialized".
>
> > I've some stale data collected on an x86 QEMU instance.
> > For 0x00 stack initialization:
> >  - hackbench, netperf and parallel Linux build were virtually free
> > (slowdown within stdev)
> >  - for af_inet_loopback the slowdown was ~4%
> > For 0xAA stack initialization:
> >  - netperf and parallel Linux build were free
> >  - for hackbench the slowdown was ~1.5%
> >  - for af_inet_loopback the slowdown was ~7%
>
> So I would expect that we have some special cases where we end up
> having arrays (or big structures) on the stack that end up being
> critical, and where initializing them is clearly  abad idea.
>
> Then we can verify manually are very much initialized, and that we
> could then mark and say "this is uninitialized".
>
> So when a compiler has an option to initialize stack variables, it
> would probably _also_ be a very good idea for that compiler to then
> support a variable attribute that says "don't initialize _this_
> variable, I will do that manually".
FWIW Clang has __attribute((uninitialized)) already:
https://reviews.llvm.org/rL349442
I agree that making it in GCC is easier if initialization itself is
implemented as part of GCC.

> But if we in ten years had a kernel model where only allocations and
> variables that were _explicitly_ uninitialized, that would be lovely.
>
> Then you can grep for those and verify that "yes, this is safe".
>
> We've historically had the reverse model - things are uninitialized by
> default, and you have to explicitly initialize them. Turning that on
> its head is what I would like to do long-term.
>
> (For normal allocations that wouldn't be too bad: get rid of
> __GFP_ZERO and friends, and instead do __GFP_UNINITIALIZED).
There've been concerns about such flags easily going out of control
(my original proposal for heap initialization contained such a flag).
To some extent their spread can be prevented by build-time checks, but
a simple grep can be insufficient, as people will start creating
helper functions to allocate with __GFP_UNINITIALIZED.

> Again - I don't think we want a world where everything is
> force-initialized. There _are_ going to be situations where that just
> hurts too much. But if we get to a place where we are zero-initialized
> by default, and have to explicitly mark the unsafe things (and we'll
> have comments not just about how they get initialized, but also about
> why that particular thing is so performance-critical), that would be a
> good place to be.
>
> This, btw, is why I also think that the "initialize with poison" is
> pointless and wrong. Yes, it can find bugs, but it doesn't really help
> improve the general situation, and people see it as a debugging tool,
> not a "improve code quality and improve the life of kernel developers"
> tool.
This sure makes sense. If this policy is adopted kernel-wide, we won't
need any debugging tools for uninit variables, so it's natural to
initialize them to zero.
>                 Linus



-- 
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

Powered by blists - more mailing lists