Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Sat, 9 Dec 2017 00:54:21 +0300
From: Alexander Popov <>
To: Peter Zijlstra <>
Cc:, Kees Cook <>,
 PaX Team <>, Brad Spengler <>,
 Ingo Molnar <>, Andy Lutomirski <>,
 Tycho Andersen <>, Laura Abbott <>,
 Mark Rutland <>,
 Ard Biesheuvel <>, Borislav Petkov <>,
 Thomas Gleixner <>, "H . Peter Anvin" <>,
Subject: Re: [PATCH RFC v6 1/6] x86/entry: Add STACKLEAK erasing the kernel
 stack at the end of syscalls

Hello Peter,

On 08.12.2017 14:44, Peter Zijlstra wrote:
> On Wed, Dec 06, 2017 at 02:33:42AM +0300, Alexander Popov wrote:
>> The STACKLEAK feature erases the kernel stack before returning from
>> syscalls. That reduces the information which kernel stack leak bugs can
>> reveal and blocks some uninitialized stack variable attacks. Moreover,
>> STACKLEAK provides runtime checks for kernel stack overflow detection.
>> This commit introduces the architecture-specific code filling the used
>> part of the kernel stack with a poison value before returning to the
>> userspace. Full STACKLEAK feature also contains the gcc plugin which
>> comes in a separate commit.
> Have you looked at the entry rework in this series:

Thanks for the link. I briefly looked through WIP.x86/pti branch. Should I
rebase STACKLEAK patch series onto it?

Although I don't fully understand some of the commits, I can suppose that
STACKLEAK stack erasing must be modified because of this trampoline stack

Am I right? Are there other changes which I should consider?

May I also ask for your feedback on this version of the STACKLEAK patch series?

Best regards,

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.