Re: [Xen-devel] [PATCH 2/4] x86: suppress SMAP and SMEP while running 32-bit PV guest code

[Andrew Cooper <andrew.cooper3@xxxxxxxxxx>]

On 09/03/16 13:35, Wu, Feng wrote:
>
>> -----Original Message-----
>> From: Jan Beulich [mailto:jbeulich@xxxxxxxx]
>> Sent: Wednesday, March 9, 2016 8:37 PM
>> To: andrew.cooper3@xxxxxxxxxx; Wu, Feng <feng.wu@xxxxxxxxx>; xen-
>> devel@xxxxxxxxxxxxxxxxxxxx
>> Cc: keir@xxxxxxx
>> Subject: Re: [PATCH 2/4] x86: suppress SMAP and SMEP while running 32-bit PV
>> guest code
>>
>>>>>> Andrew Cooper <andrew.cooper3@xxxxxxxxxx> 03/09/16 1:33 PM >>>
>>> On 09/03/16 12:27, Wu, Feng wrote:
>>>> Oh, thanks for the clarification! Do you know how "An NMI or #MC may
>> occur
>>>> between clearing CR4.SMEP and CR4.SMAP in compat_restore_all_guest and
>>>> it actually returning to guest context, in which case the guest would run 
>>>> with
>>>> the two features enabled. " can happen? Especially how the guest can run
>>>> with the two features enabled?
>>> NMIs and MCEs can occur at any point, even if interrupts are disabled.
>>>
>>> The bad situation is this sequence:
>>>
>>> * Xen is returning to the guest and disables CR4.SMEP/SMAP
>>> * NMI occurs while still in Xen
>>> * NMI exit path sees it is returning to Xen and re-enabled CR4.SMEP/SMAP
>> Well, almost: Re-enabling happens on the NMI entry path. The NMI exit
>> path would, seeing it's returning to Xen context, simply not disable them
>> again.
> Thinking about this again, in this case, when the NMI happens, we are in
> Xen context (CPL in cs is 0), so the CPL of the saved cs in stack is 0,right?
> why do we re-enable CR4.SMEP/SMAP in this case? I mean do we only
> need to enable SMEP/SMAP when coming from 32bit pv guest (CPL of cs is 1) ?

We always want Xen to be running with SMEP/SMAP enabled.  Therefore the
safer and simpler option is to always enable them if we observe them
disabled.

Interrupting a 32bit PV guest might end up seeing a cpl of 1 or 3, and
peeking into the active struct domain to check is_pv32_domain would be a
larger overhead on the entry paths.

~Andrew

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel