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

[H. Peter Anvin]

On 04/23/2014 10:08 AM, Andrew Lutomirski wrote:
> 
> The only way I can see to trigger the race is with sigreturn, but it's
> still there.  Sigh.
> 

I don't see why sigreturn needs to be involved... all you need is
modify_ldt() on one CPU while the other is in the middle of an IRET
return.  Small window, so hard to hit, but still.

> 2. I've often pondered changing the way we return *to* CPL 0 to bypass
> iret entirely.  It could be something like:
> 
> SS
> RSP
> EFLAGS
> CS
> RIP
> 
> push 16($rsp)
> popfq [does this need to force rex.w somehow?]
> ret $64

When you say return to CPL 0 you mean intra-kernel return?  That isn't
really the problem here, though.  I think this will also break the
kernel debugger since it will have the wrong behavior for TF and RF.

>>> The other question I have is - is there any reason we can't fix up the
>>> IRET to do a 32bit return into a vsyscall type userspace page which then
>>> does a long jump or retf to the right place ?
>>
>> I did a writeup on this a while ago.  It does have the problem that you
>> need additional memory in userspace, which is per-thread and in the
>> right region of userspace; this pretty much means you have to muck about
>> with the user space stack when user space is running in weird modes.
>> This gets complex very quickly and does have some "footprint".
>> Furthermore, on some CPUs (not including any recent Intel CPUs) there is
>> still a way to leak bits [63:32].  I believe the in-kernel solution is
>> actually simpler.
>>
> 
> There's also no real guarantee that user code won't unmap the vdso.

There is, but there is also at some point a "don't do that, then" aspect
to it all.

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