summaryrefslogtreecommitdiffstats
path: root/arch/x86/xen/xen-asm_32.S
diff options
context:
space:
mode:
authorJan Beulich <jbeulich@suse.com>2019-11-11 15:32:59 +0100
committerThomas Gleixner <tglx@linutronix.de>2019-11-19 21:58:28 +0100
commit922eea2ce5c799228d9ff1be9890e6873ce8fff6 (patch)
tree32e78a83ff9255e5e773bf3e25f04b34d762e655 /arch/x86/xen/xen-asm_32.S
parent29b810f5a5ec127d3143770098e05981baa3eb77 (diff)
downloadtalos-op-linux-922eea2ce5c799228d9ff1be9890e6873ce8fff6.tar.gz
talos-op-linux-922eea2ce5c799228d9ff1be9890e6873ce8fff6.zip
x86/xen/32: Simplify ring check in xen_iret_crit_fixup()
This can be had with two instead of six insns, by just checking the high CS.RPL bit. Also adjust the comment - there would be no #GP in the mentioned cases, as there's no segment limit violation or alike. Instead there'd be #PF, but that one reports the target EIP of said branch, not the address of the branch insn itself. Signed-off-by: Jan Beulich <jbeulich@suse.com> Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Reviewed-by: Juergen Gross <jgross@suse.com> Link: https://lkml.kernel.org/r/a5986837-01eb-7bf8-bf42-4d3084d6a1f5@suse.com
Diffstat (limited to 'arch/x86/xen/xen-asm_32.S')
-rw-r--r--arch/x86/xen/xen-asm_32.S15
1 files changed, 4 insertions, 11 deletions
diff --git a/arch/x86/xen/xen-asm_32.S b/arch/x86/xen/xen-asm_32.S
index 392e033e40b9..cd177772fe4d 100644
--- a/arch/x86/xen/xen-asm_32.S
+++ b/arch/x86/xen/xen-asm_32.S
@@ -153,22 +153,15 @@ hyper_iret:
* it's still on stack), we need to restore its value here.
*/
ENTRY(xen_iret_crit_fixup)
- pushl %ecx
/*
* Paranoia: Make sure we're really coming from kernel space.
* One could imagine a case where userspace jumps into the
* critical range address, but just before the CPU delivers a
- * GP, it decides to deliver an interrupt instead. Unlikely?
- * Definitely. Easy to avoid? Yes. The Intel documents
- * explicitly say that the reported EIP for a bad jump is the
- * jump instruction itself, not the destination, but some
- * virtual environments get this wrong.
+ * PF, it decides to deliver an interrupt instead. Unlikely?
+ * Definitely. Easy to avoid? Yes.
*/
- movl 3*4(%esp), %ecx /* nested CS */
- andl $SEGMENT_RPL_MASK, %ecx
- cmpl $USER_RPL, %ecx
- popl %ecx
- je 2f
+ testb $2, 2*4(%esp) /* nested CS */
+ jnz 2f
/*
* If eip is before iret_restore_end then stack
OpenPOWER on IntegriCloud