From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Jan Beulich <JBeulich@suse.com>
Cc: xen-devel <xen-devel@lists.xenproject.org>,
Keir Fraser <keir@xen.org>, Feng Wu <feng.wu@intel.com>,
Andrew Cooper <andrew.cooper3@citrix.com>
Subject: Re: [PATCH v3 2/4] x86: suppress SMEP and SMAP while running 32-bit PV guest code
Date: Fri, 25 Mar 2016 14:01:18 -0400 [thread overview]
Message-ID: <20160325180117.GC20741@char.us.oracle.com> (raw)
In-Reply-To: <56EA72C402000078000DD92F@prv-mh.provo.novell.com>
> @@ -174,10 +174,61 @@ compat_bad_hypercall:
> /* %rbx: struct vcpu, interrupts disabled */
> ENTRY(compat_restore_all_guest)
> ASSERT_INTERRUPTS_DISABLED
> +.Lcr4_orig:
> + ASM_NOP8 /* testb $3,UREGS_cs(%rsp) */
> + ASM_NOP2 /* jpe .Lcr4_alt_end */
> + ASM_NOP8 /* mov CPUINFO_cr4...(%rsp), %rax */
> + ASM_NOP6 /* and $..., %rax */
> + ASM_NOP8 /* mov %rax, CPUINFO_cr4...(%rsp) */
> + ASM_NOP3 /* mov %rax, %cr4 */
> +.Lcr4_orig_end:
> + .pushsection .altinstr_replacement, "ax"
> +.Lcr4_alt:
> + testb $3,UREGS_cs(%rsp)
> + jpe .Lcr4_alt_end
This would jump if the last operation had even bits set. And the
'testb' is 'and' operation which would give us the '011' (for $3).
Why not just depend on the ZF ? Other places that test UREGS_cs()
look to be using that?
> + mov CPUINFO_cr4-CPUINFO_guest_cpu_user_regs(%rsp), %rax
> + and $~(X86_CR4_SMEP|X86_CR4_SMAP), %rax
> + mov %rax, CPUINFO_cr4-CPUINFO_guest_cpu_user_regs(%rsp)
> + mov %rax, %cr4
> +.Lcr4_alt_end:
> + .section .altinstructions, "a"
> + altinstruction_entry .Lcr4_orig, .Lcr4_alt, X86_FEATURE_SMEP, \
> + (.Lcr4_orig_end - .Lcr4_orig), \
> + (.Lcr4_alt_end - .Lcr4_alt)
> + altinstruction_entry .Lcr4_orig, .Lcr4_alt, X86_FEATURE_SMAP, \
> + (.Lcr4_orig_end - .Lcr4_orig), \
> + (.Lcr4_alt_end - .Lcr4_alt)
> + .popsection
> RESTORE_ALL adj=8 compat=1
> .Lft0: iretq
> _ASM_PRE_EXTABLE(.Lft0, handle_exception)
>
> +/* This mustn't modify registers other than %rax. */
> +ENTRY(cr4_pv32_restore)
> + push %rdx
> + GET_CPUINFO_FIELD(cr4, %rdx)
> + mov (%rdx), %rax
> + test $X86_CR4_SMEP|X86_CR4_SMAP,%eax
> + jnz 0f
> + or cr4_pv32_mask(%rip), %rax
> + mov %rax, %cr4
> + mov %rax, (%rdx)
Here you leave %rax with the cr4_pv32_mask value, but:
> + pop %rdx
> + ret
> +0:
> +#ifndef NDEBUG
> + /* Check that _all_ of the bits intended to be set actually are. */
> + mov %cr4, %rax
> + and cr4_pv32_mask(%rip), %eax
> + cmp cr4_pv32_mask(%rip), %eax
> + je 1f
> + BUG
> +1:
> +#endif
> + pop %rdx
> + xor %eax, %eax
.. Here you clear it. Any particular reason?
> + ret
> +
> /* %rdx: trap_bounce, %rbx: struct vcpu */
> ENTRY(compat_post_handle_exception)
> testb $TBF_EXCEPTION,TRAPBOUNCE_flags(%rdx)
.. snip..
> -.macro LOAD_C_CLOBBERED compat=0
> +.macro LOAD_C_CLOBBERED compat=0 ax=1
> .if !\compat
> movq UREGS_r11(%rsp),%r11
> movq UREGS_r10(%rsp),%r10
> movq UREGS_r9(%rsp),%r9
> movq UREGS_r8(%rsp),%r8
> -.endif
> +.if \ax
> movq UREGS_rax(%rsp),%rax
> +.endif
Why the .endif here considering you are doing an:
> +.elseif \ax
an else if here?
> + movl UREGS_rax(%rsp),%eax
> +.endif
Actually, Why two 'if ax' ? checks?
Or am I reading this incorrect?
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
next prev parent reply other threads:[~2016-03-25 18:01 UTC|newest]
Thread overview: 67+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-03-04 11:08 [PATCH 0/4] x86: accommodate 32-bit PV guests with SMAP/SMEP handling Jan Beulich
2016-03-04 11:27 ` [PATCH 1/4] x86/alternatives: correct near branch check Jan Beulich
2016-03-07 15:43 ` Andrew Cooper
2016-03-07 15:56 ` Jan Beulich
2016-03-07 16:11 ` Andrew Cooper
2016-03-07 16:21 ` Jan Beulich
2016-03-08 17:33 ` Andrew Cooper
2016-03-04 11:27 ` [PATCH 2/4] x86: suppress SMAP and SMEP while running 32-bit PV guest code Jan Beulich
2016-03-07 16:59 ` Andrew Cooper
2016-03-08 7:57 ` Jan Beulich
2016-03-09 8:09 ` Wu, Feng
2016-03-09 14:09 ` Jan Beulich
2016-03-09 11:19 ` Andrew Cooper
2016-03-09 14:28 ` Jan Beulich
2016-03-09 8:09 ` Wu, Feng
2016-03-09 10:45 ` Andrew Cooper
2016-03-09 12:27 ` Wu, Feng
2016-03-09 12:33 ` Andrew Cooper
2016-03-09 12:36 ` Jan Beulich
2016-03-09 12:54 ` Wu, Feng
2016-03-09 13:35 ` Wu, Feng
2016-03-09 13:42 ` Andrew Cooper
2016-03-09 14:03 ` Jan Beulich
2016-03-09 14:07 ` Jan Beulich
2016-03-04 11:28 ` [PATCH 3/4] x86: use optimal NOPs to fill the SMAP/SMEP placeholders Jan Beulich
2016-03-07 17:43 ` Andrew Cooper
2016-03-08 8:02 ` Jan Beulich
2016-03-04 11:29 ` [PATCH 4/4] x86: use 32-bit loads for 32-bit PV guest state reload Jan Beulich
2016-03-07 17:45 ` Andrew Cooper
2016-03-10 9:44 ` [PATCH v2 0/3] x86: accommodate 32-bit PV guests with SMEP/SMAP handling Jan Beulich
2016-03-10 9:53 ` [PATCH v2 1/3] x86: suppress SMEP and SMAP while running 32-bit PV guest code Jan Beulich
2016-05-13 15:48 ` Andrew Cooper
2016-03-10 9:54 ` [PATCH v2 2/3] x86: use optimal NOPs to fill the SMEP/SMAP placeholders Jan Beulich
2016-05-13 15:49 ` Andrew Cooper
2016-03-10 9:55 ` [PATCH v2 3/3] x86: use 32-bit loads for 32-bit PV guest state reload Jan Beulich
[not found] ` <56E9A0DB02000078000DD54C@prv-mh.provo.novell.com>
2016-03-17 7:50 ` [PATCH v3 0/4] x86: accommodate 32-bit PV guests with SMEP/SMAP handling Jan Beulich
2016-03-17 8:02 ` [PATCH v3 1/4] x86: move cached CR4 value to struct cpu_info Jan Beulich
2016-03-17 16:20 ` Andrew Cooper
2016-03-17 8:03 ` [PATCH v3 2/4] x86: suppress SMEP and SMAP while running 32-bit PV guest code Jan Beulich
2016-03-25 18:01 ` Konrad Rzeszutek Wilk [this message]
2016-03-29 6:55 ` Jan Beulich
2016-05-13 15:58 ` Andrew Cooper
2016-03-17 8:03 ` [PATCH v3 3/4] x86: use optimal NOPs to fill the SMEP/SMAP placeholders Jan Beulich
2016-05-13 15:57 ` Andrew Cooper
2016-05-13 16:06 ` Jan Beulich
2016-05-13 16:09 ` Andrew Cooper
2016-03-17 8:04 ` [PATCH v3 4/4] x86: use 32-bit loads for 32-bit PV guest state reload Jan Beulich
2016-03-25 18:02 ` Konrad Rzeszutek Wilk
2016-03-17 16:14 ` [PATCH v3 5/4] x86: reduce code size of struct cpu_info member accesses Jan Beulich
2016-03-25 18:47 ` Konrad Rzeszutek Wilk
2016-03-29 6:59 ` Jan Beulich
2016-03-30 14:28 ` Konrad Rzeszutek Wilk
2016-03-30 14:42 ` Jan Beulich
2016-05-13 16:11 ` Andrew Cooper
2016-05-03 13:58 ` Ping: [PATCH v3 2/4] x86: suppress SMEP and SMAP while running 32-bit PV guest code Jan Beulich
2016-05-03 14:10 ` Andrew Cooper
2016-05-03 14:25 ` Jan Beulich
2016-05-04 10:03 ` Andrew Cooper
2016-05-04 13:35 ` Jan Beulich
2016-05-04 3:07 ` Wu, Feng
2016-05-13 15:21 ` Wei Liu
2016-05-13 15:30 ` Jan Beulich
2016-05-13 15:33 ` Wei Liu
2016-05-13 17:02 ` [PATCH v3 0/4] x86: accommodate 32-bit PV guests with SMEP/SMAP handling Wei Liu
2016-05-13 17:21 ` Andrew Cooper
2016-06-21 6:19 ` Wu, Feng
2016-06-21 7:17 ` Jan Beulich
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20160325180117.GC20741@char.us.oracle.com \
--to=konrad.wilk@oracle.com \
--cc=JBeulich@suse.com \
--cc=andrew.cooper3@citrix.com \
--cc=feng.wu@intel.com \
--cc=keir@xen.org \
--cc=xen-devel@lists.xenproject.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.