[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CA+55aFyONQeyHit6LcQz_JM5+C9pr61fcWFSpdn=7K_2mZN+oA@mail.gmail.com>
Date: Thu, 25 Jan 2018 10:48:01 -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 Mon, Jan 22, 2018 at 10:55 AM, Linus Torvalds
<torvalds@...ux-foundation.org> wrote:
>
> Honestly, I'd rather get rid of the fast-path entirely. Compared to
> all the PTI mess, it's not even noticeable.
So I looked at how that would be.
Patch attached. Not really "tested", but I'm running the kernel with
this patch now, and 'strace' etc works, and honestly, it seems very
obvious.
Also, code generation for 'do_syscall_64()' does not look horrible. In
fact, it doesn't look all that much worse than the fast-path ever did.
So the biggest impact of this is the extra register saves
(SAVE_EXTRA_REGS) from setting up the full ptregs. And honestly, I
hate how that stupid macro still uses "movq reg,off(%rsp)" instead of
"pushq %reg".
Considering the diffstat:
2 files changed, 2 insertions(+), 121 deletions(-)
and how those 100+ lines are nasty assembly code, I do think we should
just do it.
Comments?
Linus
View attachment "patch.diff" of type "text/plain" (5124 bytes)
Powered by blists - more mailing lists