lkml.org 
[lkml]   [2014]   [Apr]   [22]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
SubjectRe: [PATCH] x86-64: espfix for 64-bit mode *PROTOTYPE*
From
On Tue, Apr 22, 2014 at 4:17 PM, H. Peter Anvin <hpa@zytor.com> wrote:
> On 04/22/2014 12:55 PM, Brian Gerst wrote:
>> On Tue, Apr 22, 2014 at 2:51 PM, H. Peter Anvin <hpa@zytor.com> wrote:
>>> On 04/22/2014 11:17 AM, Brian Gerst wrote:
>>>>>
>>>>> That is the entry condition that we have to deal with. The fact that
>>>>> the switch to the IST is unconditional is what makes ISTs hard to deal with.
>>>>
>>>> Right, that is why you switch away from the IST as soon as possible,
>>>> copying the data that is already pushed there to another stack so it
>>>> won't be overwritten by a recursive fault.
>>>>
>>>
>>> That simply will not work if you can take a #GP due to the "safe" MSR
>>> functions from NMI and #MC context, which would be my main concern.
>>
>> In that case (#2 above), you would switch to the previous %rsp (in the
>> NMI/MC stack), copy the exception frame from the IST, and continue
>> with the #GP handler. That effectively is the same as it is today,
>> where no stack switch occurs on the #GP fault.
>>
>
> 1. You take #GP. This causes an IST stack switch.
> 2. You immediately thereafter take an NMI. This switches stacks again.
> 3. Now you take another #GP. This causes another IST stack, and now you
> have clobbered your return information, and cannot resume.

You are right. That will not work.


\
 
 \ /
  Last update: 2014-04-23 01:41    [W:0.553 / U:0.036 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site