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>
In-Reply-To: <201907281507.B3F11DD54@keescook>
From:   Alexander Potapenko <glider@google.com>
Date:   Tue, 30 Jul 2019 15:53:19 +0200
Message-ID: <CAG_fn=Us9wREo+9PG-jPCTXsNv-rencgYHowtwXahuYBgdDs4A@mail.gmail.com>
Subject: Re: [GIT PULL] meminit fix for v5.3-rc2
To:     Kees Cook <keescook@chromium.org>
Cc:     Linus Torvalds <torvalds@linux-foundation.org>,
        Linux List Kernel Mailing <linux-kernel@vger.kernel.org>,
        Arnd Bergmann <arnd@arndb.de>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

Hi Kees, Linus,

On Mon, Jul 29, 2019 at 12:16 AM Kees Cook <keescook@chromium.org> wrote:
>
> On Sun, Jul 28, 2019 at 12:43:15PM -0700, Linus Torvalds wrote:
> > On Sun, Jul 28, 2019 at 12:21 PM Kees Cook <keescook@chromium.org> wrot=
e:
> > >
> > > Please pull this meminit fix for v5.3-rc2.
> >
> > Side noe: I find "meminit" a confusing description for the structleak
> > thing. When I hear it, it sounds like some generic memory
> > initialization thing in the VM layer (which we obviously do also
> > have), not the stack variable initialization.
>
> I will find a better name. :) We dreamed up "meminit" as finding a name
> for the umbrella of both stack and heap auto-initialization. But I
> agree, it's confusing.
>
> > Also, have you guys talked to gcc people about just making it a real
> > feature, like I think it is for clang? In particular, I still suspect
> > that we could/should  just make zero-filling the *default* in the long
> > run, and say "our C standard is that local variables are initialized
> > to zero, exactly the same way static variables are".
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.

> Yes, this is on the list for discussion at Plumber's. Having gcc do
> auto-init is the first part. Convincing Clang that _zero_ init isn't
> a language-breaking change is the second part. :P That's been a whole
> other issue.
>
> > I know you posted some numbers somewhere (well, I'm pretty sure you
> > did) and the full stack initialization really was pretty cheap,
> > wasn't it?
>
> Yes, Clang's initialization (which is 0xAA not 0x00 in most cases) is
> cheap. There are rumors(?) of some pathological workloads, though. I
> haven't seen real numbers for that though.
>
> I'll try to find the Clang numbers (maybe Alexander has them?) but I
> remember it being the same as (or maybe better than) the gcc-plugin
> version, which I measured here:

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%

Since then we've made some improvements to Clang (and more are coming,
e.g. cross-function DSE in https://reviews.llvm.org/D61879), so I
expect the performance numbers to be better now.
A big chunk of slowdown had been caused by DSE not working well with
inline assembly on x86, need to check what's the current status there.

Lately I've been mostly benchmarking Android system performance using
the hwuimacro benchmark suite (an end-to-end benchmark for various UI
features).
Most of the benchmarks are unaffected by stack initialization, however
there are cases in which the slowdown is up to 5% for no obvious
reason (the hottest functions don't have initialization code in them,
slowdown could be related to increased icache pressure).

The biggest problem is that there's no single slowdown number to report.
Benchmarks like netperf may show big slowdowns, but many systems don't
run under netperf-like load 24/7
For graphical apps it's critical that the user doesn't notice the UI
glitches introduced by the instrumentation, so benchmarks exploiting
the full graphical stack are a lot more interesting.
Those often have big variance though, and are very specific to the
particular system.

Alex

> https://git.kernel.org/linus/81a56f6dcd20
>
> --
> Kees Cook


--
Alexander Potapenko
Software Engineer

Google Germany GmbH
Erika-Mann-Stra=C3=9Fe, 33
80636 M=C3=BCnchen

Gesch=C3=A4ftsf=C3=BChrer: Paul Manicle, Halimah DeLaine Prado
Registergericht und -nummer: Hamburg, HRB 86891
Sitz der Gesellschaft: Hamburg