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
Mime-Version: 1.0 (1.0)
Subject: Re: [PATCH v3 1/7] x86/ldt: refresh %fs and %gs in refresh_ldt_segments()
From:   Andy Lutomirski <luto@amacapital.net>
In-Reply-To: <408ed97a-c64d-c523-c403-4e066d1f34c3@intel.com>
Date:   Fri, 22 Jun 2018 11:47:48 -0700
Cc:     Andy Lutomirski <luto@kernel.org>,
        LKML <linux-kernel@vger.kernel.org>,
        "H. Peter Anvin" <hpa@linux.intel.com>,
        "H. Peter Anvin" <hpa@zytor.com>, Ingo Molnar <mingo@kernel.org>,
        Thomas Gleixner <tglx@linutronix.de>,
        "Bae, Chang Seok" <chang.seok.bae@intel.com>,
        "Metzger, Markus T" <markus.t.metzger@intel.com>
Content-Transfer-Encoding: quoted-printable
Message-Id: <FB113DE3-5841-49B2-A11E-CE785EF0C763@amacapital.net>
References: <20180621211754.12757-1-h.peter.anvin@intel.com> <20180621211754.12757-2-h.peter.anvin@intel.com> <CALCETrWerhEUMw+JS4p5MVEopiMnUjbUtX58Ci7UYfYT=Y5Cvw@mail.gmail.com> <408ed97a-c64d-c523-c403-4e066d1f34c3@intel.com>
To:     "H. Peter Anvin" <h.peter.anvin@intel.com>
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk


> On Jun 22, 2018, at 11:29 AM, H. Peter Anvin <h.peter.anvin@intel.com> wro=
te:
>=20
>> On 06/22/18 07:24, Andy Lutomirski wrote:
>>=20
>> That RPL3 part is false.  The following program does:
>>=20
>> #include <stdio.h>
>>=20
>> int main()
>> {
>>    unsigned short sel;
>>    asm volatile ("mov %%ss, %0" : "=3Drm" (sel));
>>    sel &=3D ~3;
>>    printf("Will write 0x%hx to GS\n", sel);
>>    asm volatile ("mov %0, %%gs" :: "rm" (sel & ~3));
>>    asm volatile ("mov %%gs, %0" : "=3Drm" (sel));
>>    printf("GS =3D 0x%hx\n", sel);
>>    return 0;
>> }
>>=20
>> prints:
>>=20
>> Will write 0x28 to GS
>> GS =3D 0x28
>>=20
>> The x86 architecture is *insane*.
>>=20
>> Other than that, this patch seems generally sensible.  But my
>> objection that it's incorrect with FSGSBASE enabled for %fs and %gs
>> still applies.
>>=20
>=20
> Ugh, you're right... I misremembered.  The CPL simply overrides the RPL
> rather than trapping.
>=20
> We still need to give legacy applications which have zero idea about the
> separate bases that apply only to 64-bit mode a way to DTRT.  Requiring
> these old crufty applications to do something new is not an option.

>=20
> As ugly as it is, I'm thinking the Right Thing is to simply make it a
> part of the Linux ABI that if the FS or GS selector registers point into
> the LDT then we will requalify them; if a 64-bit app does that then they
> get that behavior.  This isn't something that will happen
> asynchronously, and if a 64-bit process loads an LDT value into FS or
> GS, they are considered to have opted in to that behavior.

But the old and crusty apps don=E2=80=99t depend on requalification because w=
e never used to do it.

I=E2=80=99m not convinced we ever need to refresh the base. In fact, we coul=
d start preserving the base of LDT-referencing FS/GS across context switches=
 even without FSGSBASE at some minor performance cost, but I don=E2=80=99t r=
eally see the point. I still think my proposed semantics are easy to impleme=
nt and preserve the ABI even if they have the sad property that the FSGSBASE=
 behavior and the non-FSGSBASE behavior end up different.

>=20
> The only other sensible option is to conditionalize this on the affected
> process being in !64-bit mode.  I don't like that myself.

Please no.

I really wish Intel had made WRGSBASE at CPL 3 require GS=3D=3D0. The curren=
t ISA was a mistake.

>=20
>    -hpa