Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Wed, 28 Mar 2018 13:13:48 -0700
From: Kees Cook <>
To: Alexander Popov <>
Cc: Kernel Hardening <>, PaX Team <>, 
	Brad Spengler <>, Ingo Molnar <>, 
	Andy Lutomirski <>, Tycho Andersen <>, Laura Abbott <>, 
	Mark Rutland <>, Ard Biesheuvel <>, 
	Borislav Petkov <>, Richard Sandiford <>, 
	Thomas Gleixner <>, "H . 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 <>, Nicholas Piggin <>, 
	Al Viro <>, "David S . Miller" <>, 
	Ding Tianhong <>, David Woodhouse <>, 
	Josh Poimboeuf <>, Steven Rostedt <>, 
	Dominik Brodowski <>, Juergen Gross <>, 
	Greg Kroah-Hartman <>, Dan Williams <>, 
	Dave Hansen <>, Mathias Krause <>, 
	Vikas Shivappa <>, Kyle Huey <>, 
	Dmitry Safonov <>, Will Deacon <>, 
	Arnd Bergmann <>, Florian Weimer <>, 
	Boris Lukashev <>, X86 ML <>, 
	LKML <>
Subject: Re: [PATCH RFC v10 0/6] Introduce the STACKLEAK feature and a test
 for it

On Wed, Mar 28, 2018 at 12:57 PM, Alexander Popov <> wrote:
> This is the 10th version of the patch series introducing STACKLEAK to the
> mainline kernel. The previous version raised a fervent discussion[0].
> The assembly code introduced by v9 irritated the reviewers.

Thanks for persisting!

> I've found the way to bypass the obstacles[1] of the C implementation.
> So I dare come once again. Let me ask you to look at this code without
> preconception.

The assembly changes are now very minimal; thanks for reworking this.
I hope this addresses both Dave Hansen and Linus's (similar)

>  1. reduces the information that can be revealed through kernel stack leak bugs.
>     The idea of erasing the thread stack at the end of syscalls is similar to
>     CONFIG_PAGE_POISONING and memzero_explicit() in kernel crypto, which all
>     comply with FDP_RIP.2 (Full Residual Information Protection) of the
>     Common Criteria standard.

Agreed: I continue to believe this is meaningful even if just for
reducing the lifetime of sensitive data on the stack.


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.