[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <95d330b0-33fc-1937-c031-e8ecd6fbbc8b@redhat.com>
Date: Wed, 14 Mar 2018 15:16:33 +0100
From: Florian Weimer <fweimer@...hat.com>
To: Linus Torvalds <torvalds@...ux-foundation.org>,
Kees Cook <keescook@...omium.org>
Cc: 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 03/12/2018 06:09 PM, Linus Torvalds wrote:
> The only complaint I have is that the Fortran front-end already has
> (some of) that functionality, and calls it something else, and allows
> you to specify more exactly what you want to clear.
>
> Florian, are you aware of the Fortran flags?
>
> -finit-local-zero
> -finit-derived
> -finit-integer=n
> -finit-real=<zero|inf|-inf|nan|snan>
> -finit-logical=<true|false>
> -finit-character=n
>
> they aren't perfect for C, but some of them do make sense at least
> conceptually: things like being able to specify whether arrays and
> structures should be initialized (-finit-derived is kind of relevant)
> might make sense.
I think I was aware of those when I put together the GCC patch, but it's
been a while, so I don't know for sure.
>> - the kernel needs a way to "opt out" of this for places where later
>> functions will do the initialization. Something like
>> __attribute__((no_automatic_variable_init)) ?
>
> Yes, that's going to make it more palatable to some uses.
>
> However, somebody who knows gcc needs to verify that it does the right
> things when inlining happens.
Given that the initializer is added in the parser, we should be able to
look at the current function definition and get the attribute from
there. Only if you want to do some special for nested functions, it's
going to be tricky. Once the initializer is there, it will survive
inlining, of course.
> Good point. It uses build_constructor() with an empty constructor, so
> it *should* be 100% equivalent to
>
> struct xyz var = { };
>
> if I understand correctly, but I'm not sure what that will do with padding.
There is no guarantee WRT padding if I understand this correctly. But
not initializing padding would be less efficient, so GCC should do the
right thing here. But this really needs to be careful checking by
someone familiar with the middle-end and the relevant backends.
Note that this patch was only for measuring the performance impact, so I
didn't polish these finer points.
>> - Can we retain the uninitialized variable usage warning? (with an
>> updated text; maybe "variable used without explicit initialization,
>> using zero-initialization"?)
>
> I think that fundamentally goes away, because all later phases see
> fully initialized state.
Yes, retaining the warning will need a completely different approach.
Thanks,
Florian
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.
