linux-kernel - Re: [PATCH v3 1/7] x86/ldt: refresh %fs and %gs in refresh_ldt

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]

Date:   Fri, 22 Jun 2018 11:47:48 -0700
From:   Andy Lutomirski <luto@...capital.net>
To:     "H. Peter Anvin" <h.peter.anvin@...el.com>
Cc:     Andy Lutomirski <luto@...nel.org>,
        LKML <linux-kernel@...r.kernel.org>,
        "H. Peter Anvin" <hpa@...ux.intel.com>,
        "H. Peter Anvin" <hpa@...or.com>, Ingo Molnar <mingo@...nel.org>,
        Thomas Gleixner <tglx@...utronix.de>,
        "Bae, Chang Seok" <chang.seok.bae@...el.com>,
        "Metzger, Markus T" <markus.t.metzger@...el.com>
Subject: Re: [PATCH v3 1/7] x86/ldt: refresh %fs and %gs in refresh_ldt_segments()




> On Jun 22, 2018, at 11:29 AM, H. Peter Anvin <h.peter.anvin@...el.com> 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