linux-kernel - Re: [PATCH] x86: Remove force

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAMzpN2i+DrKkzDyiS6Cj61LmCu+--e5puQpKrNxYVMDRPMvvBw@mail.gmail.com>
Date:   Fri, 20 Dec 2019 07:18:02 -0500
From:   Brian Gerst <brgerst@...il.com>
To:     David Laight <David.Laight@...lab.com>
Cc:     Andy Lutomirski <luto@...nel.org>, X86 ML <x86@...nel.org>,
        LKML <linux-kernel@...r.kernel.org>,
        Ingo Molnar <mingo@...nel.org>,
        "H . Peter Anvin" <hpa@...or.com>,
        Boris Ostrovsky <boris.ostrovsky@...cle.com>,
        Oleg Nesterov <oleg@...hat.com>
Subject: Re: [PATCH] x86: Remove force_iret()

On Fri, Dec 20, 2019 at 5:10 AM David Laight <David.Laight@...lab.com> wrote:
>
> From: Brian Gerst
> > Sent: 20 December 2019 03:48
> > On Thu, Dec 19, 2019 at 8:50 PM Andy Lutomirski <luto@...nel.org> wrote:
> > >
> > > On Thu, Dec 19, 2019 at 3:58 AM Brian Gerst <brgerst@...il.com> wrote:
> > > >
> > > > force_iret() was originally intended to prevent the return to user mode with
> > > > the SYSRET or SYSEXIT instructions, in cases where the register state could
> > > > have been changed to be incompatible with those instructions.
> > >
> > > It's more than that.  Before the big syscall rework, we didn't restore
> > > the caller-saved regs.  See:
> > >
> > > commit 21d375b6b34ff511a507de27bf316b3dde6938d9
> > > Author: Andy Lutomirski <luto@...nel.org>
> > > Date:   Sun Jan 28 10:38:49 2018 -0800
> > >
> > >     x86/entry/64: Remove the SYSCALL64 fast path
> > >
> > > So if you changed r12, for example, the change would get lost.
> >
> > force_iret() specifically dealt with changes to CS, SS and EFLAGS.
> > Saving and restoring the extra registers was a different problem
> > although it affected the same functions like ptrace, signals, and
> > exec.
>
> Is it ever possible for any of the segment registers to refer to the LDT
> and for another thread to invalidate the entries 'very late' ?
> So even though the values were valid when changed, they are
> invalid during the 'return to user' sequence.

Not in the SYSRET case, where the kernel requires that CS and SS are
static segments in the GDT.  Any userspace context that uses LDT
segments for CS/SS must return with IRET.  There is fault handling for
IRET (fixup_bad_iret()) for this case.

> I remember writing a signal handler that 'corrupted' all the
> segment registers (etc) and fixing the NetBSD kernel to handle
> all the faults restoring the segment registers and IRET faulting
> in kernel (IIRC invalid user %SS or %CS).
> (IRET can also fault in user space, but that is a normal fault.)
>
> Is it actually cheaper to properly validate the segment registers,
> or take the 'hit' of the slightly slower IRET path and get the cpu
> to do it for you?

SYSRET is faster because it avoids segment table lookups and
permission checks for CS and SS.  It simply sets the selectors to
values set in an MSR and the attributes (base, limit, etc.) to fixed
values.  It is up to the OS to make sure the actual segment
descriptors in memory match those default attributes.

--
Brian Gerst