Messages in this thread | | | Date | Tue, 22 Apr 2014 23:24:04 -0700 | From | "H. Peter Anvin" <> | Subject | Re: [PATCH] x86-64: espfix for 64-bit mode *PROTOTYPE* |
| |
On 04/22/2014 10:04 AM, Linus Torvalds wrote: > > The segment table is shared for a process. So you can have one thread > doing a load_ldt() that invalidates a segment, while another thread is > busy taking a page fault. The segment was valid at page fault time and > is saved on the kernel stack, but by the time the page fault returns, > it is no longer valid and the iretq will fault. > > Anyway, if done correctly, this whole espfix should be totally free > for normal processes, since it should only trigger if SS is a LDT > entry (bit #2 set in the segment descriptor). So the normal fast-path > should just have a simple test for that. > > And if you have a SS that is a descriptor in the LDT, nobody cares > about performance any more. >
I just realized that with the LDT being a process-level object (unlike the GDT), we need to remove the filtering on the espfix hack, both for 32-bit and 64-bit kernels. Otherwise there is a race condition between executing the LAR instruction in the filter and the IRET, which could allow the leak to become manifest.
The "good" part is that I think the espfix hack is harmless even with a 32/64-bit stack segment, although it has a substantial performance penalty.
Does anyone have any idea if there is a real use case for non-16-bit LDT segments used as the stack segment? Does Wine use anything like that?
Very old NPTL Linux binaries use LDT segments, but only for data segments.
-hpa
| |