Date: Mon, 23 Oct 2017 10:08:30 +0100 From: Mark Rutland <mark.rutland@....com> To: Peter Zijlstra <peterz@...radead.org> Cc: Alexander Popov <alex.popov@...ux.com>, kernel-hardening@...ts.openwall.com, keescook@...omium.org, pageexec@...email.hu, spender@...ecurity.net, Ingo Molnar <mingo@...nel.org>, Andy Lutomirski <luto@...nel.org>, tycho@...ker.com, Laura Abbott <labbott@...hat.com>, Ard Biesheuvel <ard.biesheuvel@...aro.org>, Borislav Petkov <bp@...en8.de>, Thomas Gleixner <tglx@...utronix.de>, "H . Peter Anvin" <hpa@...or.com>, x86@...nel.org Subject: Re: [PATCH RFC v5 0/5] Introduce the STACKLEAK feature and a test for it On Sun, Oct 22, 2017 at 03:11:57PM +0200, Peter Zijlstra wrote: > On Sun, Oct 22, 2017 at 03:22:48AM +0300, Alexander Popov wrote: > > Further work > > ============= > > > > - Rewrite erase_kstack() in C (if Ingo Molnar insists). > > Aside from legacy, is there any sane reason that stuff is in ASM? That > is, I too will insist it being in C unless you can provide good > arguments on why it needs be asm. All it does is memzero() right? And I > would think architectures already have fairly optimized implementations > of that around. One argument for this being in asm is that you can't control the stack usage of a C implementation of erase_kstack(), which leaves a (small) portion of the stack potentially not cleared depending on what exactly the compiler does with the stack. If it's just a call to memzero(), the asm should be very simple, and I'd think it's better to err on the side of clearing as much of the stack as possible. Thanks, Mark.
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.