Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Mon, 12 Mar 2018 10:45:30 -0700
From: Linus Torvalds <>
To: Kees Cook <>
Cc: Ingo Molnar <>, P J P <>, 
	Florian Weimer <>, Ard Biesheuvel <>, 
	Steven Rostedt <>, Arnd Bergmann <>, 
	Daniel Micay <>, Dave Hansen <>, 
	Alexander Popov <>, 
	Kernel Hardening <>, PaX Team <>, 
	Brad Spengler <>, Andy Lutomirski <>, 
	Tycho Andersen <>, Laura Abbott <>, Mark Rutland <>, 
	Borislav Petkov <>, Richard Sandiford <>, 
	Thomas Gleixner <>, "H . Peter Anvin" <>, 
	Peter Zijlstra <>, "Dmitry V . Levin" <>, 
	Emese Revfy <>, Jonathan Corbet <>, 
	Andrey Ryabinin <>, 
	"Kirill A . Shutemov" <>, Thomas Garnier <>, 
	Andrew Morton <>, Alexei Starovoitov <>, Josef Bacik <>, 
	Masami Hiramatsu <>, Nicholas Piggin <>, 
	Al Viro <>, "David S . Miller" <>, 
	Ding Tianhong <>, David Woodhouse <>, 
	Josh Poimboeuf <>, Dominik Brodowski <>, 
	Juergen Gross <>, Greg Kroah-Hartman <>, 
	Dan Williams <>, Mathias Krause <>, 
	Vikas Shivappa <>, Kyle Huey <>, 
	Dmitry Safonov <>, Will Deacon <>, X86 ML <>, 
	LKML <>
Subject: Re: Fully initialized stack usage (was Re: [PATCH RFC v9 4/7]
 x86/entry: Erase kernel stack in syscall_trace_enter())

On Mon, Mar 12, 2018 at 10:17 AM, Kees Cook <> wrote:
> On Mon, Mar 12, 2018 at 10:09 AM, Linus Torvalds
> <> wrote:
>>     struct xyz var = { };
>> I'm not sure what that will do with padding.
> AIUI, this does not guarantee padding initialization (yet another
> "undefined behavior"). This is why we've had to sprinkle memset(&var,
> 0, sizeof(var)) in places where a structure has padding and got
> leaked. :(
> I assume this may be orthogonal to -finit-local-vars, and maybe we'll
> need some -finit-padding or something. (Though, honestly, is there
> anyone that wants to get _padding_ correct, but not variable
> initialization?)

We would definitely have wanted it over the years, yes. And
conceptually it's a separate issue, so a separate flag makes sense.

But for the kernel, if we have -finit-local-vars, we'd just use that,
so you're right that _we_ don't care, and I don't know if anybody else
does either.

Maybe some security-conscious project would, though. I can definitely
see some project going "we always initialize our stuff ourselves, but
we still worry about padding".

So a separate flag for that would make a lot of sense.

> I'm fine with it going away, though I share Jeff Law's observation in
> Florian's gcc thread that we lose some potentially useful warnings
> ("oops, it took a while to track down this bug, since that variable
> had been zero initialized; I wish I knew that had happened", etc.) And
> when the kernel entirely depends on auto-zero-init, we could just add
> -Wno-maybe-uninitialized. *shrug*

I think it's actually _fundamentally_ hard to give the "might be used
uninitialized" warning together with "-finit-local-vars".

You have to introduce a whole new "zero but counts as uninitialized" model.

So I suspect the gcc people would be better off doing the reverse of
what you suggest: tell people to simply do test builds without

For example, for the kernel, we already have that
"CONFIG_COMPILE_TEST" explicitly for the case of "build but don't use"
for build coverage. So it would make sense for us to only use
"-finit-local-vars" when COMPILE_TEST is _not_ set. That would give us
the warnings for our coverage, but all "real" builds would be built
with the initializations.


Powered by blists - more mailing lists

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.