Messages in this thread | | | Subject | Re: [PATCH v3 1/7] x86/ldt: refresh %fs and %gs in refresh_ldt_segments() | From | "H. Peter Anvin" <> | Date | Fri, 22 Jun 2018 11:29:45 -0700 |
| |
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
| |