[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Thu, 12 Jul 2018 22:50:16 +0200
From: Ingo Molnar <mingo@...nel.org>
To: Kees Cook <keescook@...omium.org>
Cc: Linus Torvalds <torvalds@...ux-foundation.org>,
Alexander Popov <alex.popov@...ux.com>,
Kernel Hardening <kernel-hardening@...ts.openwall.com>,
Pax Team <pageexec@...email.hu>,
Brad Spengler <spender@...ecurity.net>,
Andrew Lutomirski <luto@...nel.org>,
Tycho Andersen <tycho@...ho.ws>, Laura Abbott <labbott@...hat.com>,
Mark Rutland <mark.rutland@....com>,
Ard Biesheuvel <ard.biesheuvel@...aro.org>,
Borislav Petkov <bp@...en8.de>,
Richard Sandiford <richard.sandiford@....com>,
Thomas Gleixner <tglx@...utronix.de>, 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>,
Nick Piggin <npiggin@...il.com>, Al Viro <viro@...iv.linux.org.uk>,
David Miller <davem@...emloft.net>,
dingtianhong <dingtianhong@...wei.com>,
David Woodhouse <dwmw@...zon.co.uk>,
Josh Poimboeuf <jpoimboe@...hat.com>,
Steven Rostedt <rostedt@...dmis.org>,
Dominik Brodowski <linux@...inikbrodowski.net>,
Jürgen Groß <jgross@...e.com>,
Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
Dan Williams <dan.j.williams@...el.com>,
Dave Hansen <dave.hansen@...ux.intel.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>, Arnd Bergmann <arnd@...db.de>,
Florian Weimer <fweimer@...hat.com>,
Boris Lukashev <blukashev@...pervictus.com>,
Andrey Konovalov <andreyknvl@...gle.com>,
the arch/x86 maintainers <x86@...nel.org>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v14 0/6] Introduce the STACKLEAK feature and a test for it
* Kees Cook <keescook@...omium.org> wrote:
> > So I agree that it's pretty stupid. Since 95%+ of our users just use what the
> > distro configured - so at minimum I'd like to see a runtime patching based way
> > for root to disable it, so that people (who care or who are hurt by it) can
> > turn the check off - which should be the most expensive part causing much of
> > the 1% overhead.
> >
> > Shouldn't be too hard to implement, this is just a checking method called for
> > every system call that does nothing substantial in 99.99999% of the cases.
>
> I'd like to not have this be required for initial inclusion.
>
> [...] Most people interested in this feature build their own kernels.
If no distro is going to enable this then why are we even pursuing this feature?
What I'm asking for is probably just a single trivial static key in the first
iteration, patched to NOP by default ... Am I missing something?
I'm 90% certain that much of the kernel build time overhead will go away with
flipping that switch.
> [...] Improving on this to make it available to all distros will be excellent,
> and I think we can do it with static keys or alternatives (?). I'd prefer this
> feature request not block the merge for 4.19, though. Would that be reasonable?
If no distro is pursuing this then there's no rush to merge this whatsoever:
people who build their own kernels can apply patches or pull in trees just as
well, right?
This whole feature is a pretty horrible idea that I can see distros enabling due
to security theatre. Let's make sure informed users have an easy runtime way out
from the worst of the overhead that doesn't involve "recompile your distro
kernel". Also, make it easier to measure and fingerpoint the overhead...
Thanks,
Ingo
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.
