| |
|
 |
|
 |
|
|
|
| |
|
|
xen-devel
[Xen-devel] RE: [PATCH v2] Enable SMEP CPU feature support for XEN hyper
> > That needs
> > 1) inject SMEP faults back to the 32-bit pv guest.
> > 2) let the guest see SMEP thru CPUID and config it in CR4 (actually it's
> > already set, but just to let guest see it).
> >
> > Anything else?
>
> I thought about this myself and realised that we can't let PV guests control
> this feature if we want Xen to benefit from it. There's little point in a
> feature to protect Xen from guests, if an untrusted guest can turn it off!
>
> Hence I think we probably have to leave the feature always on for PV guests.
> Unless we find some guests are incompatible with that.
As we talked, 64-bit pv kernel can't trigger SMEP faults. So we decided to not
let it see this feature.
Maybe it's okay to inject SMEP faults which are triggered from 32-bit pv
kernel back to it even the guest is not aware of SMEP.
We can refer to Linux SMEP patch, which just turns this feature on without
touching any page table handling functions as SMEP handling actually can
reuse NX handling code path. Ingo wanted to expose SMEP to KVM guest
silently, but it is not architecturally right as it's required to flush TLB when
CR4.SMEP is changed, or a kernel page is changed to user page. But luckily
Linux doesn't have such cases thus doesn't need to flush TLB.
Thanks!
-Xin
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
|
|
| |
|
Home