Re: [Patch v4 2/4] Add SMEP handling when setting CR4

[Avi Kivity <avi@redhat.com>]

On 06/01/2011 03:32 PM, Marcelo Tosatti wrote:
> On Tue, May 31, 2011 at 10:03:26PM +0300, Avi Kivity wrote:
> >  On 05/31/2011 09:48 PM, Marcelo Tosatti wrote:
> >  >On Tue, May 31, 2011 at 09:05:35PM +0300, Avi Kivity wrote:
> >  >>   >>     	if (is_long_mode(vcpu)) {
> >  >>   >>     		if (!(cr4&    X86_CR4_PAE))
> >  >>   >>     			return 1;
> >  >>   >
> >  >>   >A new field in vcpu->arch.mmu.base_role for smep is required
> >  >>   >for shadow MMU (similar to nxe).
> >  >>
> >  >>   I plan to add that with my cr0.wp=0 fixup (it's only needed there, right?)
> >  >
> >  >Sptes instantiated when cr4.smep = 0 should not be used when cr4.smep =
> >  >1, so no (unlikely that guest kernel executes user=1 code anyway, but
> >  >for consistency with other base_role flags).
> >
> >  Why not?  The sptes are interpreted exactly the same.
> >
> >  sptes are interpreted differently when efer.nxe=1 - if bit 63 is
> >  set, it will fault when nxe=0 and will not fault when nxe=1 (for
> >  non-fetch accesses).  So we can't share those sptes.
>
> A) CR4.SMEP = 0, spte instantiated via fetch fault of user pte.
> B) CR4.SMEP = 1, base_role unchanged.
> C) spte instantiated in A) used, but access should fault instead.
>
> Or if you have multiple CPUs with different settings.

Why would C) not fault?  The spte has U=1, any fetch access from kernel 
mode with SMEP=1 will fault.

-- 
error compiling committee.c: too many arguments to function