Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
From:   Andy Lutomirski <luto@amacapital.net>
Mime-Version: 1.0 (1.0)
Subject: Re: [PATCH] x86: Remove force_iret()
Date:   Sat, 21 Dec 2019 05:20:46 +0800
Message-Id: <A5CA1E6B-B755-4F5A-8813-10713C1C192C@amacapital.net>
References: <227c8442919d44a790370870aaba416c@AcuMS.aculab.com>
Cc:     Brian Gerst <brgerst@gmail.com>, Andy Lutomirski <luto@kernel.org>,
        X86 ML <x86@kernel.org>, LKML <linux-kernel@vger.kernel.org>,
        Ingo Molnar <mingo@kernel.org>,
        "H . Peter Anvin" <hpa@zytor.com>,
        Boris Ostrovsky <boris.ostrovsky@oracle.com>,
        Oleg Nesterov <oleg@redhat.com>
In-Reply-To: <227c8442919d44a790370870aaba416c@AcuMS.aculab.com>
To:     David Laight <David.Laight@aculab.com>
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk


> On Dec 20, 2019, at 6:59 PM, David Laight <David.Laight@aculab.com> wrote:=

>=20
> =EF=BB=BFFrom: Andy Lutomirski
>> Sent: 20 December 2019 10:30
>>>> On Dec 20, 2019, at 6:10 PM, David Laight <David.Laight@aculab.com> wro=
te:
>>>=20
>>> =EF=BB=BFFrom: Brian Gerst
>>>> Sent: 20 December 2019 03:48
>>>>> On Thu, Dec 19, 2019 at 8:50 PM Andy Lutomirski <luto@kernel.org> wrot=
e:
>>>>>=20
>>>>> On Thu, Dec 19, 2019 at 3:58 AM Brian Gerst <brgerst@gmail.com> wrote:=

>>>>>>=20
>>>>>> force_iret() was originally intended to prevent the return to user mo=
de with
>>>>>> the SYSRET or SYSEXIT instructions, in cases where the register state=
 could
>>>>>> have been changed to be incompatible with those instructions.
>>>>>=20
>>>>> It's more than that.  Before the big syscall rework, we didn't restore=

>>>>> the caller-saved regs.  See:
>>>>>=20
>>>>> commit 21d375b6b34ff511a507de27bf316b3dde6938d9
>>>>> Author: Andy Lutomirski <luto@kernel.org>
>>>>> Date:   Sun Jan 28 10:38:49 2018 -0800
>>>>>=20
>>>>>   x86/entry/64: Remove the SYSCALL64 fast path
>>>>>=20
>>>>> So if you changed r12, for example, the change would get lost.
>>>>=20
>>>> 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.
>>>=20
>>> 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' ?
>>=20
>> Not in newer kernels, because the actual LDT is never modified.
>> Instead, LDT changes create a whole new LDT and propagate it with an IPI.=

>=20
> Can the IPI be disabled through the SYSRET path?

There=E2=80=99s a whole dance in prepare_exit_to_usermode().  We turn off in=
terrupts, then check for pending work (which does not include this IPI, but i=
ncludes plenty of other nasty things), and we keep interrupts off until we a=
re in user mode.

> Once in user space, the IPI will interrupt the process and, I presume, it w=
ill
> pick up the new LDT on 'return to user'.

The new LDT is picked up in the IPI callback.

> But if the IPI happens between the LDT being set and SYSRET it will (presu=
mably)
> remain 'pending' until the next system call?
> Which could be long enough for one thread to have passed a pointer across g=
iving
> an unexpected SEGV (or maybe worse, failing to give an expected one).

modify_ldt() won=E2=80=99t return until all threads have the new LDT.=