[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CA+55aFxMDAaQ-d3ktWCjcob8OQARcE=OWFXNJtQnW62rF-XY0g@mail.gmail.com>
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