2019-01-16 00:17:10

by Jan Beulich

[permalink] [raw]
Subject: [PATCH v3] x86-64/Xen: fix stack switching

While in the native case entry into the kernel happens on the trampoline
stack, PV Xen kernels get entered with the current thread stack right
away. Hence source and destination stacks are identical in that case,
and special care is needed.

Other than in sync_regs() the copying done on the INT80 path isn't
NMI / #MC safe, as either of these events occurring in the middle of the
stack copying would clobber data on the (source) stack.

I'm not altering the similar code in interrupt_entry() and nmi(), as
those code paths are unreachable afaict when running PV Xen guests.

Fixes: 7f2590a110b837af5679d08fc25c6227c5a8c497
Signed-off-by: Jan Beulich <[email protected]>
Cc: [email protected]
---
v3: Drop NMI path change. Use ALTERNATIVE.
v2: Correct placement of .Lint80_keep_stack label.
---
arch/x86/entry/entry_64_compat.S | 6 ++++--
1 file changed, 4 insertions(+), 2 deletions(-)

--- 5.0-rc2/arch/x86/entry/entry_64_compat.S
+++ 5.0-rc2-x86_64-stack-switch-Xen/arch/x86/entry/entry_64_compat.S
@@ -361,7 +361,8 @@ ENTRY(entry_INT80_compat)

/* Need to switch before accessing the thread stack. */
SWITCH_TO_KERNEL_CR3 scratch_reg=%rdi
- movq %rsp, %rdi
+ /* In the Xen PV case we already run on the thread stack. */
+ ALTERNATIVE "movq %rsp, %rdi", "jmp .Lint80_keep_stack", X86_FEATURE_XENPV
movq PER_CPU_VAR(cpu_current_top_of_stack), %rsp

pushq 6*8(%rdi) /* regs->ss */
@@ -370,8 +371,9 @@ ENTRY(entry_INT80_compat)
pushq 3*8(%rdi) /* regs->cs */
pushq 2*8(%rdi) /* regs->ip */
pushq 1*8(%rdi) /* regs->orig_ax */
-
pushq (%rdi) /* pt_regs->di */
+.Lint80_keep_stack:
+
pushq %rsi /* pt_regs->si */
xorl %esi, %esi /* nospec si */
pushq %rdx /* pt_regs->dx */






2019-01-17 01:25:31

by Andy Lutomirski

[permalink] [raw]
Subject: Re: [PATCH v3] x86-64/Xen: fix stack switching

On Tue, Jan 15, 2019 at 8:58 AM Jan Beulich <[email protected]> wrote:
>
> While in the native case entry into the kernel happens on the trampoline
> stack, PV Xen kernels get entered with the current thread stack right
> away. Hence source and destination stacks are identical in that case,
> and special care is needed.
>
> Other than in sync_regs() the copying done on the INT80 path isn't
> NMI / #MC safe, as either of these events occurring in the middle of the
> stack copying would clobber data on the (source) stack.
>
> I'm not altering the similar code in interrupt_entry() and nmi(), as
> those code paths are unreachable afaict when running PV Xen guests.


Acked-by: Andy Lutomirski <[email protected]>

2019-01-17 04:50:03

by Jürgen Groß

[permalink] [raw]
Subject: Re: [PATCH v3] x86-64/Xen: fix stack switching

On 15/01/2019 17:58, Jan Beulich wrote:
> While in the native case entry into the kernel happens on the trampoline
> stack, PV Xen kernels get entered with the current thread stack right
> away. Hence source and destination stacks are identical in that case,
> and special care is needed.
>
> Other than in sync_regs() the copying done on the INT80 path isn't
> NMI / #MC safe, as either of these events occurring in the middle of the
> stack copying would clobber data on the (source) stack.
>
> I'm not altering the similar code in interrupt_entry() and nmi(), as
> those code paths are unreachable afaict when running PV Xen guests.
>
> Fixes: 7f2590a110b837af5679d08fc25c6227c5a8c497
> Signed-off-by: Jan Beulich <[email protected]>
> Cc: [email protected]

Reviewed-by: Juergen Gross <[email protected]>


Juergen

Subject: [tip:x86/urgent] x86/entry/64/compat: Fix stack switching for XEN PV

Commit-ID: fc24d75a7f91837d7918e40719575951820b2b8f
Gitweb: https://git.kernel.org/tip/fc24d75a7f91837d7918e40719575951820b2b8f
Author: Jan Beulich <[email protected]>
AuthorDate: Tue, 15 Jan 2019 09:58:16 -0700
Committer: Thomas Gleixner <[email protected]>
CommitDate: Fri, 18 Jan 2019 00:39:33 +0100

x86/entry/64/compat: Fix stack switching for XEN PV

While in the native case entry into the kernel happens on the trampoline
stack, PV Xen kernels get entered with the current thread stack right
away. Hence source and destination stacks are identical in that case,
and special care is needed.

Other than in sync_regs() the copying done on the INT80 path isn't
NMI / #MC safe, as either of these events occurring in the middle of the
stack copying would clobber data on the (source) stack.

There is similar code in interrupt_entry() and nmi(), but there is no fixup
required because those code paths are unreachable in XEN PV guests.

[ tglx: Sanitized subject, changelog, Fixes tag and stable mail address. Sigh ]

Fixes: 7f2590a110b8 ("x86/entry/64: Use a per-CPU trampoline stack for IDT entries")
Signed-off-by: Jan Beulich <[email protected]>
Signed-off-by: Thomas Gleixner <[email protected]>
Reviewed-by: Juergen Gross <[email protected]>
Acked-by: Andy Lutomirski <[email protected]>
Cc: Peter Anvin <[email protected]>
Cc: [email protected]>
Cc: Boris Ostrovsky <[email protected]>
Cc: [email protected]
Link: https://lkml.kernel.org/r/[email protected]

---
arch/x86/entry/entry_64_compat.S | 6 ++++--
1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/arch/x86/entry/entry_64_compat.S b/arch/x86/entry/entry_64_compat.S
index 8eaf8952c408..39913770a44d 100644
--- a/arch/x86/entry/entry_64_compat.S
+++ b/arch/x86/entry/entry_64_compat.S
@@ -361,7 +361,8 @@ ENTRY(entry_INT80_compat)

/* Need to switch before accessing the thread stack. */
SWITCH_TO_KERNEL_CR3 scratch_reg=%rdi
- movq %rsp, %rdi
+ /* In the Xen PV case we already run on the thread stack. */
+ ALTERNATIVE "movq %rsp, %rdi", "jmp .Lint80_keep_stack", X86_FEATURE_XENPV
movq PER_CPU_VAR(cpu_current_top_of_stack), %rsp

pushq 6*8(%rdi) /* regs->ss */
@@ -370,8 +371,9 @@ ENTRY(entry_INT80_compat)
pushq 3*8(%rdi) /* regs->cs */
pushq 2*8(%rdi) /* regs->ip */
pushq 1*8(%rdi) /* regs->orig_ax */
-
pushq (%rdi) /* pt_regs->di */
+.Lint80_keep_stack:
+
pushq %rsi /* pt_regs->si */
xorl %esi, %esi /* nospec si */
pushq %rdx /* pt_regs->dx */