[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [PATCH V2] xen: support enabling SMEP/SMAP for HVM only



On Thu, Aug 11, 2016 at 07:14:06AM -0600, Jan Beulich wrote:
> >>> On 11.08.16 at 11:17, <he.chen@xxxxxxxxxxxxxxx> wrote:
> > @@ -1404,12 +1438,20 @@ void __init noreturn __start_xen(unsigned long 
> > mbi_p)
> >      if ( !opt_smep )
> >          setup_clear_cpu_cap(X86_FEATURE_SMEP);
> >      if ( cpu_has_smep )
> > +    {
> >          set_in_cr4(X86_CR4_SMEP);
> > +        if ( smep_hvm_only )
> > +            write_cr4(read_cr4() & ~X86_CR4_SMEP);
> > +    }
> 
> So that'll clear CR4.SMEP right here, but won't help with CR4 loads
> from mmu_cr4_features (as e.g. happens indirectly during VM exits,
> since the HOST_CR4 field gets set from this variable).
> 
> Did you in fact test your change, including validation of the features
> correctly remaining off over the lifetime of the system?
> 
> Further, considering that you don't clear the two flags from Xen's
> internal feature bitmap, and taken together with the internal feature
> bitmap driving alternative instruction patching, I'd assume pointless
> (and performance wise perhaps harmful) patching to now take place.
> 
Let me see whether I understand this correctly...

Regarding alternative instruction patching, if enabling SMAP for HVM but
disabling it for Xen, SMAP bit must be set in x86_capability feature
bitmap and cleared in mmu_cr4_features, which means instruction patching
would take place and a #UD may occur (since SMAP is disable in Xen, but
STAC/CLAC are patched and called).

A little dirty solution I can think of now is to temperarily clear SMAP
bit in x86_capability before patching instruction and then set it back
when instruction patching finish, like:

```
if ( opt_smap == SMAP_HVM_ONLY )
    setup_clear_cpu_cap(X86_FEATURE_SMAP);

alternative_instructions();

if ( opt_smap == SMAP_HVM_ONLY )
    __set_bit(X86_FEATURE_SMAP, boot_cpu_data.x86_capability);
```

Appreciate it if you have a better solution.

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

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.