x86/xen/32: Simplify ring check in xen_iret_crit_fixup() (922eea2c) · Commits · 戴 / test

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

arch/x86/xen/xen-asm_32.S

+4 −11

Original line number	Diff line number	Diff line
		@@ -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 34(%esp), %ecx / nested CS */
		andl $SEGMENT_RPL_MASK, %ecx
		cmpl $USER_RPL, %ecx
		popl %ecx
		je 2f
		testb $2, 24(%esp) / nested CS */
		jnz 2f

		/*
		* If eip is before iret_restore_end then stack

Admin message