Re: [PATCH v3 1/7] x86/ldt: refresh %fs and %gs in refresh_ldt_segments()

[Andy Lutomirski]

> On Jun 22, 2018, at 11:29 AM, H. Peter Anvin <h.peter.anvin@xxxxxxxxx> wrote:
> 
>> On 06/22/18 07:24, Andy Lutomirski wrote:
>> 
>> That RPL3 part is false.  The following program does:
>> 
>> #include <stdio.h>
>> 
>> int main()
>> {
>>    unsigned short sel;
>>    asm volatile ("mov %%ss, %0" : "=rm" (sel));
>>    sel &= ~3;
>>    printf("Will write 0x%hx to GS\n", sel);
>>    asm volatile ("mov %0, %%gs" :: "rm" (sel & ~3));
>>    asm volatile ("mov %%gs, %0" : "=rm" (sel));
>>    printf("GS = 0x%hx\n", sel);
>>    return 0;
>> }
>> 
>> prints:
>> 
>> Will write 0x28 to GS
>> GS = 0x28
>> 
>> The x86 architecture is *insane*.
>> 
>> Other than that, this patch seems generally sensible.  But my
>> objection that it's incorrect with FSGSBASE enabled for %fs and %gs
>> still applies.
>> 
> 
> Ugh, you're right... I misremembered.  The CPL simply overrides the RPL
> rather than trapping.
> 
> 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.

> 
> 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ât depend on requalification because we never used to do it.

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

> 
> 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==0. The current ISA was a mistake.

> 
>    -hpa