[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20171023090829.bmddmm7463yhnqaf@salmiak>
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.
