All of lore.kernel.org
 help / color / mirror / Atom feed
From: Kees Cook <keescook@chromium.org>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Linux List Kernel Mailing <linux-kernel@vger.kernel.org>,
	Arnd Bergmann <arnd@arndb.de>,
	Alexander Potapenko <glider@google.com>
Subject: Re: [GIT PULL] meminit fix for v5.3-rc2
Date: Sun, 28 Jul 2019 15:16:28 -0700	[thread overview]
Message-ID: <201907281507.B3F11DD54@keescook> (raw)
In-Reply-To: <CAHk-=wj+1vDh2=eZExibYF9Lo0GsGxaAjxCSwpUFVURrN44cUQ@mail.gmail.com>

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> wrote:
> >
> > 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".

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:

https://git.kernel.org/linus/81a56f6dcd20

-- 
Kees Cook

  parent reply	other threads:[~2019-07-28 22:16 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-07-28 19:21 [GIT PULL] meminit fix for v5.3-rc2 Kees Cook
2019-07-28 19:43 ` Linus Torvalds
2019-07-28 19:50   ` Linus Torvalds
2019-07-28 22:16   ` Kees Cook [this message]
2019-07-30 13:53     ` Alexander Potapenko
2019-07-30 19:53       ` Linus Torvalds
2019-07-31 11:30         ` Alexander Potapenko
2019-07-28 19:50 ` pr-tracker-bot

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=201907281507.B3F11DD54@keescook \
    --to=keescook@chromium.org \
    --cc=arnd@arndb.de \
    --cc=glider@google.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=torvalds@linux-foundation.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.