Re: [PATCH] x86: entry_32.S: change ESPFIX test to not touch PT_OLDSS(%esp)
From: Andy Lutomirski
Date: Mon Mar 09 2015 - 15:52:28 EST
On Mon, Mar 9, 2015 at 12:26 PM, H. Peter Anvin <hpa@xxxxxxxxx> wrote:
> On 03/09/2015 12:13 PM, Andy Lutomirski wrote:
>> On Mon, Mar 9, 2015 at 10:44 AM, H. Peter Anvin <hpa@xxxxxxxxx> wrote:
>>> On 03/09/2015 09:44 AM, Linus Torvalds wrote:
>>>>
>>>> And remember: those zero-cost out-of-order branches turn quite
>>>> expensive if they *ever* mispredict. Even a 5% mispredict rate is
>>>> likely to mean "it's better to have a data dependency chain".
>>>>
>>>> So it could easily go either way. I'm not convinced the old code is bad at all.
>>>>
>>>
>>> I'm inclined to side with Linus here. I'm hesitant to change this based
>>> on pure speculation.
>>>
>>> To answer Andy's question: I do believe we need espfix for V86 mode as well.
>>>
>>
>> I think we don't. Did I screw up my test?
>>
>
> I don't see how your test executes V86 mode code at all, since there
> seems to be nothing mapped at the bottom of memory?
It executes the implicit #PF at the bottom of memory :)
Seriously, though, I think that IRET doesn't check whether the
instruction we're returning to can be fetched, so IRET will complete
successfully and then we'll get #PF. The resulting SIGSEGV kicks us
out of vm86 mode, and, assuming that the kernel isn't buggy (hah!) the
v86 state will get saved back to the vm86plus_struct and we can see if
esp got corrupted.
--Andy
--
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/