Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Thu, 25 Jan 2018 11:16:27 -0800
From: Linus Torvalds <torvalds@...ux-foundation.org>
To: Andy Lutomirski <luto@...nel.org>
Cc: "the arch/x86 maintainers" <x86@...nel.org>, LKML <linux-kernel@...r.kernel.org>, 
	Greg Kroah-Hartman <gregkh@...uxfoundation.org>, Alan Cox <alan@...ux.intel.com>, 
	Jann Horn <jannh@...gle.com>, Samuel Neves <samuel.c.p.neves@...il.com>, 
	Dan Williams <dan.j.williams@...el.com>, 
	Kernel Hardening <kernel-hardening@...ts.openwall.com>, Borislav Petkov <bp@...en8.de>
Subject: Re: [PATCH] x86/retpoline/entry: Disable the entire SYSCALL64 fast
 path with retpolines on

On Thu, Jan 25, 2018 at 10:48 AM, Linus Torvalds
<torvalds@...ux-foundation.org> wrote:
>
> So the biggest impact of this is the extra register saves

Actually, the other noticeable part is the reloading of the argument
registers from ptregs. Together with just the extra level of
'call/ret' and the stack setup, I'm guessing we're talking maybe 20
cycles or so.

So there's the extra register saves, and simply the fact that the
fastpath had a flatter calling structure.

It still feels worth it. And if we do decide that we want to do the
register clearing on kernel entry for some paranoid mode, we'd pretty
much have to do this anyway.

                 Linus

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.