Re: [PATCH 2/4] x86: suppress SMAP and SMEP while running 32-bit PV guest code

["Wu, Feng" <feng.wu@intel.com>]

> >> +/* This mustn't modify registers other than %rax. */
> >> +ENTRY(cr4_smep_smap_restore)
> >> +        mov   %cr4, %rax
> >> +        test  $X86_CR4_SMEP|X86_CR4_SMAP,%eax
> >> +        jnz   0f

If we clear every place where we are back to 32bit pv guest,
X86_CR4_SMEP and X86_CR4_SMAP bit should be clear
in CR4, right?  If that is the case, we cannot jump to 0f.
However, like what you mentioned in the comments below:

+        /*
+         * An NMI or #MC may occur between clearing CR4.SMEP and CR4.SMAP in
+         * compat_restore_all_guest and it actually returning to guest
+         * context, in which case the guest would run with the two features
+         * enabled. The only bad that can happen from this is a kernel mode
+         * #PF which the guest doesn't expect. Rather than trying to make the
+         * NMI/#MC exit path honor the intended CR4 setting, simply check
+         * whether the wrong CR4 was in use when the #PF occurred, and exit
+         * back to the guest (which will in turn clear the two CR4 bits) to
+         * re-execute the instruction. If we get back here, the CR4 bits
+         * should then be found clear (unless another NMI/#MC occurred at
+         * exactly the right time), and we'll continue processing the
+         * exception as normal.
+         */

That means, if NMI or #MC happens in the right time, the guest can be
running with SMAP/SMEP set in cr4, only in this case, we can get the '0f'.
Is my understanding correct? Thanks!


> >> +        or    cr4_smep_smap_mask(%rip), %rax
> >> +        mov   %rax, %cr4
> >> +        ret
> >> +0:
> >> +        and   cr4_smep_smap_mask(%rip), %eax
> >> +        cmp   cr4_smep_smap_mask(%rip), %eax
> >> +        je    1f
> >> +        BUG
> >
> > What is the purpose of this bugcheck? It looks like it is catching a
> > mismatch of masked options, but I am not completely sure.
> 
> This aims at detecting that some of the CR4 bits which are
> expected to be set really aren't (other than the case when all
> of the ones of interest here are clear).

The code in the 0f section consider the following case as not
a bug, do you think this can really happen?

Let's suppose smap it bit 0 and smep is bit1, then
cr4_smep_smap_mask is 01 or 10 and %eax is 11, in this case, it
means, Xen sets both smap and smep, but when guest is running,
only one feature is set. In your path, smap and smep is set/clear
at the same time, not sure this can happen.

BTW, I think it is worth adding some comments for the 0f section.

Thanks,
Feng



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