kernel-hardening - Re: [PATCH] x86/retpoline/entry: Disable the entire SYSCALL64 fast path with retpolines on

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 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)

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.