* [Xen-devel] [PATCH v3] x86/stackframe/32: repair 32-bit Xen PV
@ 2019-11-18 15:21 Jan Beulich
2019-11-19 8:03 ` Ingo Molnar
2019-11-19 21:01 ` [tip: x86/urgent] x86/stackframe/32: Repair " tip-bot2 for Jan Beulich
0 siblings, 2 replies; 3+ messages in thread
From: Jan Beulich @ 2019-11-18 15:21 UTC (permalink / raw)
To: Andy Lutomirski
Cc: Peter Zijlstra, xen-devel@lists.xenproject.org,
the arch/x86 maintainers
Once again RPL checks have been introduced which don't account for a
32-bit kernel living in ring 1 when running in a PV Xen domain. The
case in FIXUP_FRAME has been preventing boot. Adjust BUG_IF_WRONG_CR3
as well to guard against future uses of the macro on a code path
reachable when running in PV mode under Xen; I have to admit that I
stopped at a certain point trying to figure out whether there are
present ones.
Fixes: 3c88c692c287 ("x86/stackframe/32: Provide consistent pt_regs")
Signed-off-by: Jan Beulich <jbeulich@suse.com>
---
v3: Move USER_SEGMENT_RPL_MASK definition to segment.h. Further explain
the BUG_IF_WRONG_CR3 adjustment.
v2: Avoid #ifdef and alter comment along the lines of Andy's suggestion.
--- a/arch/x86/entry/entry_32.S
+++ b/arch/x86/entry/entry_32.S
@@ -172,7 +172,7 @@
ALTERNATIVE "jmp .Lend_\@", "", X86_FEATURE_PTI
.if \no_user_check == 0
/* coming from usermode? */
- testl $SEGMENT_RPL_MASK, PT_CS(%esp)
+ testl $USER_SEGMENT_RPL_MASK, PT_CS(%esp)
jz .Lend_\@
.endif
/* On user-cr3? */
@@ -217,7 +217,7 @@
testl $X86_EFLAGS_VM, 4*4(%esp)
jnz .Lfrom_usermode_no_fixup_\@
#endif
- testl $SEGMENT_RPL_MASK, 3*4(%esp)
+ testl $USER_SEGMENT_RPL_MASK, 3*4(%esp)
jnz .Lfrom_usermode_no_fixup_\@
orl $CS_FROM_KERNEL, 3*4(%esp)
--- a/arch/x86/include/asm/segment.h
+++ b/arch/x86/include/asm/segment.h
@@ -31,6 +31,18 @@
*/
#define SEGMENT_RPL_MASK 0x3
+/*
+ * When running on Xen PV, the actual privilege level of the kernel is 1,
+ * not 0. Testing the Requested Privilege Level in a segment selector to
+ * determine whether the context is user mode or kernel mode with
+ * SEGMENT_RPL_MASK is wrong because the PV kernel's privilege level
+ * matches the 0x3 mask.
+ *
+ * Testing with USER_SEGMENT_RPL_MASK is valid for both native and Xen PV
+ * kernels because privilege level 2 is never used.
+ */
+#define USER_SEGMENT_RPL_MASK 0x2
+
/* User mode is privilege level 3: */
#define USER_RPL 0x3
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply [flat|nested] 3+ messages in thread* Re: [Xen-devel] [PATCH v3] x86/stackframe/32: repair 32-bit Xen PV
2019-11-18 15:21 [Xen-devel] [PATCH v3] x86/stackframe/32: repair 32-bit Xen PV Jan Beulich
@ 2019-11-19 8:03 ` Ingo Molnar
2019-11-19 21:01 ` [tip: x86/urgent] x86/stackframe/32: Repair " tip-bot2 for Jan Beulich
1 sibling, 0 replies; 3+ messages in thread
From: Ingo Molnar @ 2019-11-19 8:03 UTC (permalink / raw)
To: Jan Beulich
Cc: Peter Zijlstra, xen-devel@lists.xenproject.org,
the arch/x86 maintainers, Andy Lutomirski
* Jan Beulich <jbeulich@suse.com> wrote:
> Once again RPL checks have been introduced which don't account for a
> 32-bit kernel living in ring 1 when running in a PV Xen domain. The
> case in FIXUP_FRAME has been preventing boot. Adjust BUG_IF_WRONG_CR3
> as well to guard against future uses of the macro on a code path
> reachable when running in PV mode under Xen; I have to admit that I
> stopped at a certain point trying to figure out whether there are
> present ones.
>
> Fixes: 3c88c692c287 ("x86/stackframe/32: Provide consistent pt_regs")
> Signed-off-by: Jan Beulich <jbeulich@suse.com>
> ---
> v3: Move USER_SEGMENT_RPL_MASK definition to segment.h. Further explain
> the BUG_IF_WRONG_CR3 adjustment.
> v2: Avoid #ifdef and alter comment along the lines of Andy's suggestion.
Since the breakage was introduced in v5.3, I've added a Cc: stable line.
Thanks,
Ingo
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply [flat|nested] 3+ messages in thread* [tip: x86/urgent] x86/stackframe/32: Repair 32-bit Xen PV
2019-11-18 15:21 [Xen-devel] [PATCH v3] x86/stackframe/32: repair 32-bit Xen PV Jan Beulich
2019-11-19 8:03 ` Ingo Molnar
@ 2019-11-19 21:01 ` tip-bot2 for Jan Beulich
1 sibling, 0 replies; 3+ messages in thread
From: tip-bot2 for Jan Beulich @ 2019-11-19 21:01 UTC (permalink / raw)
To: linux-tip-commits
Cc: Jan Beulich, Thomas Gleixner, Stable Team, Ingo Molnar,
Borislav Petkov, linux-kernel
The following commit has been merged into the x86/urgent branch of tip:
Commit-ID: 81ff2c37f9e5d77593928df0536d86443195fd64
Gitweb: https://git.kernel.org/tip/81ff2c37f9e5d77593928df0536d86443195fd64
Author: Jan Beulich <jbeulich@suse.com>
AuthorDate: Mon, 18 Nov 2019 16:21:12 +01:00
Committer: Thomas Gleixner <tglx@linutronix.de>
CommitterDate: Tue, 19 Nov 2019 21:58:28 +01:00
x86/stackframe/32: Repair 32-bit Xen PV
Once again RPL checks have been introduced which don't account for a 32-bit
kernel living in ring 1 when running in a PV Xen domain. The case in
FIXUP_FRAME has been preventing boot.
Adjust BUG_IF_WRONG_CR3 as well to guard against future uses of the macro
on a code path reachable when running in PV mode under Xen; I have to admit
that I stopped at a certain point trying to figure out whether there are
present ones.
Fixes: 3c88c692c287 ("x86/stackframe/32: Provide consistent pt_regs")
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Cc: Stable Team <stable@vger.kernel.org>
Link: https://lore.kernel.org/r/0fad341f-b7f5-f859-d55d-f0084ee7087e@suse.com
---
arch/x86/entry/entry_32.S | 4 ++--
arch/x86/include/asm/segment.h | 12 ++++++++++++
2 files changed, 14 insertions(+), 2 deletions(-)
diff --git a/arch/x86/entry/entry_32.S b/arch/x86/entry/entry_32.S
index f83ca5a..3f847d8 100644
--- a/arch/x86/entry/entry_32.S
+++ b/arch/x86/entry/entry_32.S
@@ -172,7 +172,7 @@
ALTERNATIVE "jmp .Lend_\@", "", X86_FEATURE_PTI
.if \no_user_check == 0
/* coming from usermode? */
- testl $SEGMENT_RPL_MASK, PT_CS(%esp)
+ testl $USER_SEGMENT_RPL_MASK, PT_CS(%esp)
jz .Lend_\@
.endif
/* On user-cr3? */
@@ -217,7 +217,7 @@
testl $X86_EFLAGS_VM, 4*4(%esp)
jnz .Lfrom_usermode_no_fixup_\@
#endif
- testl $SEGMENT_RPL_MASK, 3*4(%esp)
+ testl $USER_SEGMENT_RPL_MASK, 3*4(%esp)
jnz .Lfrom_usermode_no_fixup_\@
orl $CS_FROM_KERNEL, 3*4(%esp)
diff --git a/arch/x86/include/asm/segment.h b/arch/x86/include/asm/segment.h
index ac38929..6669164 100644
--- a/arch/x86/include/asm/segment.h
+++ b/arch/x86/include/asm/segment.h
@@ -31,6 +31,18 @@
*/
#define SEGMENT_RPL_MASK 0x3
+/*
+ * When running on Xen PV, the actual privilege level of the kernel is 1,
+ * not 0. Testing the Requested Privilege Level in a segment selector to
+ * determine whether the context is user mode or kernel mode with
+ * SEGMENT_RPL_MASK is wrong because the PV kernel's privilege level
+ * matches the 0x3 mask.
+ *
+ * Testing with USER_SEGMENT_RPL_MASK is valid for both native and Xen PV
+ * kernels because privilege level 2 is never used.
+ */
+#define USER_SEGMENT_RPL_MASK 0x2
+
/* User mode is privilege level 3: */
#define USER_RPL 0x3
^ permalink raw reply related [flat|nested] 3+ messages in thread
end of thread, other threads:[~2019-11-19 21:02 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2019-11-18 15:21 [Xen-devel] [PATCH v3] x86/stackframe/32: repair 32-bit Xen PV Jan Beulich
2019-11-19 8:03 ` Ingo Molnar
2019-11-19 21:01 ` [tip: x86/urgent] x86/stackframe/32: Repair " tip-bot2 for Jan Beulich
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.