|
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
Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.