[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <35b0d50f-12d1-10c3-f5e8-d6c140486d4a@oracle.com>
Date: Tue, 12 Jul 2022 20:20:44 +0200
From: Alexandre Chartre <alexandre.chartre@...cle.com>
To: Peter Zijlstra <peterz@...radead.org>,
Borislav Petkov <bp@...en8.de>
Cc: X86 ML <x86@...nel.org>, LKML <linux-kernel@...r.kernel.org>
Subject: UNTRAIN_RET in native_irq_return_ldt
Hi,
I think there is an issue in native_irq_return_ldt: UNTRAIN_RET is used and can
clobber %rax which is expected to be the user rax.
A simple fix would be to preserve %rax:
diff --git a/arch/x86/entry/entry_64.S b/arch/x86/entry/entry_64.S
index a4ba162e52c3..f1fe05289d84 100644
--- a/arch/x86/entry/entry_64.S
+++ b/arch/x86/entry/entry_64.S
@@ -728,7 +728,11 @@ native_irq_return_ldt:
pushq %rdi /* Stash user RDI */
swapgs /* to kernel GS */
SWITCH_TO_KERNEL_CR3 scratch_reg=%rdi /* to kernel CR3 */
+
+ /* UNTRAIN_RET can clobber %rax, so preserve it */
+ movq %rax, %rdi
UNTRAIN_RET
+ movq %rdi, %rax
movq PER_CPU_VAR(espfix_waddr), %rdi
movq %rax, (0*8)(%rdi) /* user RAX */
But I wonder if we really need to use UNTRAIN_RET in native_irq_return_ldt because
I think we reach this point from the kernel after untrain has already be done,
and it looks like we don't do ret afterward (the code just fixup the stack and
then iret).
Thanks,
alex.
Powered by blists - more mailing lists