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]

Message-ID: <408ed97a-c64d-c523-c403-4e066d1f34c3@intel.com>
Date:   Fri, 22 Jun 2018 11:29:45 -0700
From:   "H. Peter Anvin" <h.peter.anvin@...el.com>
To:     Andy Lutomirski <luto@...nel.org>
Cc:     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 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.

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

	-hpa