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 majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
