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 22:50:16 +0200
From: Ingo Molnar <>
To: Kees Cook <>
Cc: Linus Torvalds <>,
	Alexander Popov <>,
	Kernel Hardening <>,
	Pax Team <>,
	Brad Spengler <>,
	Andrew Lutomirski <>,
	Tycho Andersen <>, Laura Abbott <>,
	Mark Rutland <>,
	Ard Biesheuvel <>,
	Borislav Petkov <>,
	Richard Sandiford <>,
	Thomas Gleixner <>, 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 <>,
	Nick Piggin <>, Al Viro <>,
	David Miller <>,
	dingtianhong <>,
	David Woodhouse <>,
	Josh Poimboeuf <>,
	Steven Rostedt <>,
	Dominik Brodowski <>,
	Jürgen Groß <>,
	Greg Kroah-Hartman <>,
	Dan Williams <>,
	Dave Hansen <>,
	Mathias Krause <>,
	Vikas Shivappa <>,
	Kyle Huey <>,
	Dmitry Safonov <>,
	Will Deacon <>, Arnd Bergmann <>,
	Florian Weimer <>,
	Boris Lukashev <>,
	Andrey Konovalov <>,
	the arch/x86 maintainers <>,
	Linux Kernel Mailing List <>
Subject: Re: [PATCH v14 0/6] Introduce the STACKLEAK feature and a test for it

* Kees Cook <> 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...



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.