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]

Message-ID: <alpine.DEB.2.20.1801252204250.2203@nanos>
Date: Thu, 25 Jan 2018 22:05:05 +0100 (CET)
From: Thomas Gleixner <tglx@...utronix.de>
To: Andy Lutomirski <luto@...nel.org>
cc: Linus Torvalds <torvalds@...ux-foundation.org>, 
    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, 25 Jan 2018, Andy Lutomirski wrote:
> On Thu, Jan 25, 2018 at 10:48 AM, Linus Torvalds
> <torvalds@...ux-foundation.org> wrote:
> > 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.
> 
> Feel free to Acked-by: Andy Lutomirski <luto@...nel.org> that patch.
> 
> Or I can grab it and send it to -tip.

That would be nice, so we can route it through x86/pti which provides it
for backporting cleanly.

Thanks,

	tglx

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