From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andrew Cooper Subject: Re: [PATCH] x86: refine debugging of SMEP/SMAP fix Date: Tue, 17 May 2016 11:28:26 +0100 Message-ID: <573AF24A.3000407@citrix.com> References: <573B067302000078000EC093@prv-mh.provo.novell.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1204973040267778593==" Return-path: Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xenproject.org with esmtp (Exim 4.84_2) (envelope-from ) id 1b2cEo-0004jd-VL for xen-devel@lists.xenproject.org; Tue, 17 May 2016 10:28:31 +0000 In-Reply-To: <573B067302000078000EC093@prv-mh.provo.novell.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xen.org Sender: "Xen-devel" To: Jan Beulich , xen-devel Cc: Wei Liu List-Id: xen-devel@lists.xenproject.org --===============1204973040267778593== Content-Type: multipart/alternative; boundary="------------060607020307000404010803" --------------060607020307000404010803 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit 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. ~Andrew > > Signed-off-by: Jan Beulich > > --- 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 > .Lcr4_alt_end: > @@ -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 > BUG > 1: > #endif > > > > > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xen.org > http://lists.xen.org/xen-devel --------------060607020307000404010803 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: 8bit
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.

~Andrew


Signed-off-by: Jan Beulich <jbeulich@suse.com>

--- 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
 .Lcr4_alt_end:
@@ -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
         BUG
 1:
 #endif






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

--------------060607020307000404010803-- --===============1204973040267778593== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: inline X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KWGVuLWRldmVs IG1haWxpbmcgbGlzdApYZW4tZGV2ZWxAbGlzdHMueGVuLm9yZwpodHRwOi8vbGlzdHMueGVuLm9y Zy94ZW4tZGV2ZWwK --===============1204973040267778593==--