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

Avi Kivity
2011-06-01T12:36:23Z

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