[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <CA+55aFx+Sue=MLs34j=8-3gf-UB8LmvBhWNFXNA1aUYbUier5A@mail.gmail.com>
Date: Wed, 14 Mar 2018 09:38:07 -0700
From: Linus Torvalds <torvalds@...ux-foundation.org>
To: Florian Weimer <fweimer@...hat.com>
Cc: Kees Cook <keescook@...omium.org>, Ingo Molnar <mingo@...nel.org>,
P J P <pjp@...oraproject.org>, Ard Biesheuvel <ard.biesheuvel@...aro.org>,
Steven Rostedt <rostedt@...dmis.org>, Arnd Bergmann <arnd@...db.de>,
Daniel Micay <danielmicay@...il.com>, Dave Hansen <dave.hansen@...ux.intel.com>,
Alexander Popov <alex.popov@...ux.com>,
Kernel Hardening <kernel-hardening@...ts.openwall.com>, PaX Team <pageexec@...email.hu>,
Brad Spengler <spender@...ecurity.net>, Andy Lutomirski <luto@...nel.org>,
Tycho Andersen <tycho@...ho.ws>, Laura Abbott <labbott@...hat.com>, Mark Rutland <mark.rutland@....com>,
Borislav Petkov <bp@...en8.de>, Richard Sandiford <richard.sandiford@....com>,
Thomas Gleixner <tglx@...utronix.de>, "H . Peter Anvin" <hpa@...or.com>,
Peter Zijlstra <a.p.zijlstra@...llo.nl>, "Dmitry V . Levin" <ldv@...linux.org>,
Emese Revfy <re.emese@...il.com>, Jonathan Corbet <corbet@....net>,
Andrey Ryabinin <aryabinin@...tuozzo.com>,
"Kirill A . Shutemov" <kirill.shutemov@...ux.intel.com>, Thomas Garnier <thgarnie@...gle.com>,
Andrew Morton <akpm@...ux-foundation.org>, Alexei Starovoitov <ast@...nel.org>, Josef Bacik <jbacik@...com>,
Masami Hiramatsu <mhiramat@...nel.org>, Nicholas Piggin <npiggin@...il.com>,
Al Viro <viro@...iv.linux.org.uk>, "David S . Miller" <davem@...emloft.net>,
Ding Tianhong <dingtianhong@...wei.com>, David Woodhouse <dwmw@...zon.co.uk>,
Josh Poimboeuf <jpoimboe@...hat.com>, Dominik Brodowski <linux@...inikbrodowski.net>,
Juergen Gross <jgross@...e.com>, Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
Dan Williams <dan.j.williams@...el.com>, Mathias Krause <minipli@...glemail.com>,
Vikas Shivappa <vikas.shivappa@...ux.intel.com>, Kyle Huey <me@...ehuey.com>,
Dmitry Safonov <dsafonov@...tuozzo.com>, Will Deacon <will.deacon@....com>, X86 ML <x86@...nel.org>,
LKML <linux-kernel@...r.kernel.org>
Subject: Re: Fully initialized stack usage (was Re: [PATCH RFC v9 4/7]
x86/entry: Erase kernel stack in syscall_trace_enter())
On Wed, Mar 14, 2018 at 9:29 AM, Linus Torvalds
<torvalds@...ux-foundation.org> wrote:
>
> The second one results in good code:
>
> movl $0, 16(%rsp)
> movl $123, 20(%rsp)
>
> which is good and doesn't leave the padding uninitialized
Side note: this obviously implies that your patch already fixes
things, but funnily, it only if the structure didn't have an
initializer.
IOW, with your patch,
struct a a;
a = (struct a) ( 1, 2 };
would do the right thing for us because of an odd internal gcc
implementation detail, because that initial definition of 'a' doesn't
have an initializer, so your patch adds an empty one, and gcc seems to
always treat that as "clear the whole stricture". After that, the
structure assignment works fine and leaves the padding zero.
But a plain
struct a a = { 1, 2 };
doesn't DTRT, and leaves uninitialized bytes to be passed around.
Of course, there might be other special cases that I simply didn't
happen to trigger with my overly stupid example and testing. Maybe
sometimes gcc does structure copies or clearing using the
member-by-member model?
My quick testing seems to indicate that it's _only_ initializers that
cause this, whether they are part of the variable declaration or
afterwards.
Linus
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.
