Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
MIME-Version: 1.0
References: <201907281218.F6D2C2DD@keescook> <CAHk-=wj+1vDh2=eZExibYF9Lo0GsGxaAjxCSwpUFVURrN44cUQ@mail.gmail.com>
 <201907281507.B3F11DD54@keescook> <CAG_fn=Us9wREo+9PG-jPCTXsNv-rencgYHowtwXahuYBgdDs4A@mail.gmail.com>
In-Reply-To: <CAG_fn=Us9wREo+9PG-jPCTXsNv-rencgYHowtwXahuYBgdDs4A@mail.gmail.com>
From:   Linus Torvalds <torvalds@linux-foundation.org>
Date:   Tue, 30 Jul 2019 12:53:57 -0700
Message-ID: <CAHk-=wgTM+cN7zyUZacGQDv3DuuoA4LORNPWgb1Y_Z1p4iedNQ@mail.gmail.com>
Subject: Re: [GIT PULL] meminit fix for v5.3-rc2
To:     Alexander Potapenko <glider@google.com>
Cc:     Kees Cook <keescook@chromium.org>,
        Linux List Kernel Mailing <linux-kernel@vger.kernel.org>,
        Arnd Bergmann <arnd@arndb.de>
Content-Type: text/plain; charset="UTF-8"
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

On Tue, Jul 30, 2019 at 6:53 AM Alexander Potapenko <glider@google.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".

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

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.

                Linus