Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Thu, 12 Jul 2018 10:45:46 -0700
From: Kees Cook <keescook@...omium.org>
To: Ingo Molnar <mingo@...nel.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

On Thu, Jul 12, 2018 at 6:59 AM, Ingo Molnar <mingo@...nel.org> wrote:
>
> * Linus Torvalds <torvalds@...ux-foundation.org> wrote:
>
>> On Wed, Jul 11, 2018 at 1:37 PM Alexander Popov <alex.popov@...ux.com> wrote:
>> >
>> > This is the 14th version of the patch series introducing STACKLEAK
>> > to the mainline kernel for x86. This version comes with style changes
>> > according to the feedback from Ingo Molnar and includes Laura Abbott's
>> > modifications of scripts/Makefile.gcc-plugins.
>>
>> As before, I will repeat that I think 1% on a kernel compile (which
>> has almost no actual kernel footprint) is a huge cost, and other -
>> more kernel-centric - loads will likely see much worse performance.
>>
>> And I still think that this is stupid, and peoples time would be
>> *much* better spent on plugins that have much lower costs and get
>> pretty much the same advanytages (ie the whole "just initialize all
>> automatics to zero" thing or similar).
>>
>> But whatever. I'll just continue to tell people not to use silly
>> config options that have a high cost-to-point ratio. If people *want*
>> to waste their CPU, that's their problem.
>
> 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. 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?

-Kees

-- 
Kees Cook
Pixel Security

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.