Re: [PATCH] x86-64: espfix for 64-bit mode *PROTOTYPE*

[H. Peter Anvin]

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.
> 

The fastpath interference is:

1. Testing for an LDT SS selector before IRET.  This is actually easier
than on 32 bits, because on 64 bits the SS:RSP on the stack is always valid.

2. Testing for an RSP inside the espfix region on exception entry, so we
can switch back the stack.  This has to be done very early in the
exception entry since the espfix stack is so small.  If NMI and #MC
didn't use IST it wouldn't work at all (but neither would SYSCALL).

#2 currently saves/restores %rdi, which is also saved further down.
This is obviously wasteful.

	-hpa


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/