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 15:59:44 +0200
From: Ingo Molnar <>
To: Linus Torvalds <>
Cc: Alexander Popov <>,
	Kernel Hardening <>,
	Kees Cook <>, 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

* Linus Torvalds <> wrote:

> On Wed, Jul 11, 2018 at 1:37 PM Alexander Popov <> 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% 

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.



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.