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;
Subject: Re: [PATCH v3 1/7] x86/ldt: refresh %fs and %gs in
 refresh_ldt_segments()
To:     Andy Lutomirski <luto@kernel.org>
Cc:     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>
References: <20180621211754.12757-1-h.peter.anvin@intel.com>
 <20180621211754.12757-2-h.peter.anvin@intel.com>
 <CALCETrWerhEUMw+JS4p5MVEopiMnUjbUtX58Ci7UYfYT=Y5Cvw@mail.gmail.com>
From:   "H. Peter Anvin" <h.peter.anvin@intel.com>
Message-ID: <408ed97a-c64d-c523-c403-4e066d1f34c3@intel.com>
Date:   Fri, 22 Jun 2018 11:29:45 -0700
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101
 Thunderbird/52.8.0
MIME-Version: 1.0
In-Reply-To: <CALCETrWerhEUMw+JS4p5MVEopiMnUjbUtX58Ci7UYfYT=Y5Cvw@mail.gmail.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

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