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

Re: [Xen-devel] [PATCH] x86: refine debugging of SMEP/SMAP fix

On 17/05/16 10:54, Jan Beulich wrote:
Instead of just latching cr4_pv32_mask into %rdx, correct the found
wrong value in %cr4 (to avoid triggering another BUG). The value left
in %rdx should be sufficient for deducing cr4_pv32_mask from the
register dump.

Alternatively, you can reuse %rax (as its value is useless by this point) and leave %rdx as exactly cr4_pv32_mask.  This avoids needing a subsequent step to reverse engineer cr4_pv32_mask.

Also there is one more place for XEN_CR4_PV32_BITS to be used.

So there is.  Sorry for missing it.


Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx>

--- a/xen/arch/x86/x86_64/compat/entry.S
+++ b/xen/arch/x86/x86_64/compat/entry.S
@@ -182,7 +182,7 @@ ENTRY(compat_restore_all_guest)
         testb $3,UREGS_cs(%rsp)
         jpe   .Lcr4_alt_end
         mov   CPUINFO_cr4-CPUINFO_guest_cpu_user_regs(%rsp), %rax
-        and   $~(X86_CR4_SMEP|X86_CR4_SMAP), %rax
+        and   $~XEN_CR4_PV32_BITS, %rax
         mov   %rax, CPUINFO_cr4-CPUINFO_guest_cpu_user_regs(%rsp)
         mov   %rax, %cr4
@@ -218,8 +218,10 @@ ENTRY(cr4_pv32_restore)
         and   cr4_pv32_mask(%rip), %rax
         cmp   cr4_pv32_mask(%rip), %rax
         je    1f
-        /* Cause cr4_pv32_mask to be visible in the BUG register dump. */
-        mov   cr4_pv32_mask(%rip), %rdx
+        /* Avoid coming back here while handling the #UD we cause below. */
+        mov   %cr4, %rdx
+        or    cr4_pv32_mask(%rip), %rdx
+        mov   %rdx, %cr4

Xen-devel mailing list

Xen-devel mailing list



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