Re: [PATCH 8/8] xen/x86: Additional SMAP modes to work around buggy 32bit PV guests

[David Vrabel <david.vrabel@citrix.com>]

On 24/06/15 17:31, Andrew Cooper wrote:
> Experimentally, older Linux guests perform construction of `init` with user
> pagetable mappings.  This is fine for native systems as such a guest would not
> set CR4.SMAP itself.
> 
> However if Xen uses SMAP itself, 32bit PV guests (whose kernels run in ring1)
> are also affected.  Older Linux guests end up spinning in a loop assuming that
> the SMAP violation pagefaults are spurious, and make no further progress.
> 
> One option is to disable SMAP completely, but this is unreasonable.  A better
> alternative is to disable SMAP only in the context of 32bit PV guests, but
> reduces the effectiveness SMAP security.  A 3rd option is for Xen to fix up
> behind a 32bit guest if it were SMAP-aware.  It is a heuristic, and does
> result in a guest-visible state change, but allows Xen to keep CR4.SMAP
> unconditionally enabled.
[...]
> --- a/docs/misc/xen-command-line.markdown
> +++ b/docs/misc/xen-command-line.markdown
> @@ -1261,11 +1261,32 @@ Set the serial transmit buffer size.
>  Flag to enable Supervisor Mode Execution Protection
>  
>  ### smap
> -> `= <boolean>`
> +> `= <boolean> | compat | fixup`
>  
>  > Default: `true`
>  
> -Flag to enable Supervisor Mode Access Prevention
> +Handling of Supervisor Mode Access Prevention.
> +
> +32bit PV guest kernels qualify as supervisor code, as they execute in ring 1.
> +If Xen uses SMAP protection itself, a PV guest which is not SMAP aware may
> +suffer unexpected pagefaults which it cannot handle. (Experimentally, there
> +are 32bit PV guests which fall foul of SMAP enforcement and spin in an
> +infinite loop taking pagefaults early on boot.)
> +
> +Two further SMAP modes are introduced to work around buggy 32bit PV guests to
> +prevent functional regressions of VMs on newer hardware.  At any point if the
> +guest sets `CR4.SMAP` itself, it is deemed aware, and **compat/fixup** cease
> +to apply.

Guests that is not aware of SMAP or do not support it are not "buggy".

> +
> +A SMAP mode of **compat** causes Xen to disable `CR4.SMAP` in the context of
> +an unaware 32bit PV guest.  This prevents the guest from being subject to SMAP
> +enforcement, but also prevents Xen from benefiting from the added security
> +checks.
> +
> +A SMAP mode of **fixup** causes Xen to set `EFLAGS.AC` when discovering a SMAP
> +pagefault in the context of an unaware 32bit PV guest.  This allows Xen to
> +retain the added security from SMAP checks, but results in a guest-visible
> +state change which it might object to.

What does the PV ABI say about the use of EFLAGS.AC?  Have guests
historically been allowed to use this bit?  If so, does Xen fiddling
with it potentially break some guests?

David