From: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
To: stable@vger.kernel.org
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
patches@lists.linux.dev,
"Peter Zijlstra (Intel)" <peterz@infradead.org>,
"Borislav Petkov (AMD)" <bp@alien8.de>
Subject: [PATCH 6.1 04/15] x86/cpu: Clean up SRSO return thunk mess
Date: Thu, 24 Aug 2023 16:15:00 +0200 [thread overview]
Message-ID: <20230824141447.392496309@linuxfoundation.org> (raw)
In-Reply-To: <20230824141447.155846739@linuxfoundation.org>
From: Peter Zijlstra <peterz@infradead.org>
commit d43490d0ab824023e11d0b57d0aeec17a6e0ca13 upstream.
Use the existing configurable return thunk. There is absolute no
justification for having created this __x86_return_thunk alternative.
To clarify, the whole thing looks like:
Zen3/4 does:
srso_alias_untrain_ret:
nop2
lfence
jmp srso_alias_return_thunk
int3
srso_alias_safe_ret: // aliasses srso_alias_untrain_ret just so
add $8, %rsp
ret
int3
srso_alias_return_thunk:
call srso_alias_safe_ret
ud2
While Zen1/2 does:
srso_untrain_ret:
movabs $foo, %rax
lfence
call srso_safe_ret (jmp srso_return_thunk ?)
int3
srso_safe_ret: // embedded in movabs instruction
add $8,%rsp
ret
int3
srso_return_thunk:
call srso_safe_ret
ud2
While retbleed does:
zen_untrain_ret:
test $0xcc, %bl
lfence
jmp zen_return_thunk
int3
zen_return_thunk: // embedded in the test instruction
ret
int3
Where Zen1/2 flush the BTB entry using the instruction decoder trick
(test,movabs) Zen3/4 use BTB aliasing. SRSO adds a return sequence
(srso_safe_ret()) which forces the function return instruction to
speculate into a trap (UD2). This RET will then mispredict and
execution will continue at the return site read from the top of the
stack.
Pick one of three options at boot (evey function can only ever return
once).
[ bp: Fixup commit message uarch details and add them in a comment in
the code too. Add a comment about the srso_select_mitigation()
dependency on retbleed_select_mitigation(). Add moar ifdeffery for
32-bit builds. Add a dummy srso_untrain_ret_alias() definition for
32-bit alternatives needing the symbol. ]
Fixes: fb3bd914b3ec ("x86/srso: Add a Speculative RAS Overflow mitigation")
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de>
Link: https://lore.kernel.org/r/20230814121148.842775684@infradead.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
arch/x86/include/asm/nospec-branch.h | 5 +++
arch/x86/kernel/cpu/bugs.c | 17 ++++++++--
arch/x86/kernel/vmlinux.lds.S | 4 +-
arch/x86/lib/retpoline.S | 58 +++++++++++++++++++++++++----------
tools/objtool/arch/x86/decode.c | 2 -
5 files changed, 64 insertions(+), 22 deletions(-)
--- a/arch/x86/include/asm/nospec-branch.h
+++ b/arch/x86/include/asm/nospec-branch.h
@@ -216,9 +216,14 @@ extern void __x86_return_thunk(void);
static inline void __x86_return_thunk(void) {}
#endif
+extern void zen_return_thunk(void);
+extern void srso_return_thunk(void);
+extern void srso_alias_return_thunk(void);
+
extern void zen_untrain_ret(void);
extern void srso_untrain_ret(void);
extern void srso_untrain_ret_alias(void);
+
extern void entry_ibpb(void);
#ifdef CONFIG_RETPOLINE
--- a/arch/x86/kernel/cpu/bugs.c
+++ b/arch/x86/kernel/cpu/bugs.c
@@ -166,8 +166,13 @@ void __init cpu_select_mitigations(void)
md_clear_select_mitigation();
srbds_select_mitigation();
l1d_flush_select_mitigation();
- gds_select_mitigation();
+
+ /*
+ * srso_select_mitigation() depends and must run after
+ * retbleed_select_mitigation().
+ */
srso_select_mitigation();
+ gds_select_mitigation();
}
/*
@@ -1015,6 +1020,9 @@ do_cmd_auto:
setup_force_cpu_cap(X86_FEATURE_RETHUNK);
setup_force_cpu_cap(X86_FEATURE_UNRET);
+ if (IS_ENABLED(CONFIG_RETHUNK))
+ x86_return_thunk = zen_return_thunk;
+
if (boot_cpu_data.x86_vendor != X86_VENDOR_AMD &&
boot_cpu_data.x86_vendor != X86_VENDOR_HYGON)
pr_err(RETBLEED_UNTRAIN_MSG);
@@ -2422,10 +2430,13 @@ static void __init srso_select_mitigatio
*/
setup_force_cpu_cap(X86_FEATURE_RETHUNK);
- if (boot_cpu_data.x86 == 0x19)
+ if (boot_cpu_data.x86 == 0x19) {
setup_force_cpu_cap(X86_FEATURE_SRSO_ALIAS);
- else
+ x86_return_thunk = srso_alias_return_thunk;
+ } else {
setup_force_cpu_cap(X86_FEATURE_SRSO);
+ x86_return_thunk = srso_return_thunk;
+ }
srso_mitigation = SRSO_MITIGATION_SAFE_RET;
} else {
pr_err("WARNING: kernel not compiled with CPU_SRSO.\n");
--- a/arch/x86/kernel/vmlinux.lds.S
+++ b/arch/x86/kernel/vmlinux.lds.S
@@ -507,8 +507,8 @@ INIT_PER_CPU(irq_stack_backing_store);
"fixed_percpu_data is not at start of per-cpu area");
#endif
- #ifdef CONFIG_RETHUNK
-. = ASSERT((__ret & 0x3f) == 0, "__ret not cacheline-aligned");
+#ifdef CONFIG_RETHUNK
+. = ASSERT((zen_return_thunk & 0x3f) == 0, "zen_return_thunk not cacheline-aligned");
. = ASSERT((srso_safe_ret & 0x3f) == 0, "srso_safe_ret not cacheline-aligned");
#endif
--- a/arch/x86/lib/retpoline.S
+++ b/arch/x86/lib/retpoline.S
@@ -94,22 +94,27 @@ SYM_CODE_END(__x86_indirect_thunk_array)
.section .text.__x86.rethunk_untrain
SYM_START(srso_untrain_ret_alias, SYM_L_GLOBAL, SYM_A_NONE)
+ UNWIND_HINT_FUNC
ANNOTATE_NOENDBR
ASM_NOP2
lfence
- jmp __x86_return_thunk
+ jmp srso_alias_return_thunk
SYM_FUNC_END(srso_untrain_ret_alias)
__EXPORT_THUNK(srso_untrain_ret_alias)
.section .text.__x86.rethunk_safe
+#else
+/* dummy definition for alternatives */
+SYM_START(srso_untrain_ret_alias, SYM_L_GLOBAL, SYM_A_NONE)
+ ANNOTATE_UNRET_SAFE
+ ret
+ int3
+SYM_FUNC_END(srso_untrain_ret_alias)
#endif
-/* Needs a definition for the __x86_return_thunk alternative below. */
SYM_START(srso_safe_ret_alias, SYM_L_GLOBAL, SYM_A_NONE)
-#ifdef CONFIG_CPU_SRSO
add $8, %_ASM_SP
UNWIND_HINT_FUNC
-#endif
ANNOTATE_UNRET_SAFE
ret
int3
@@ -117,9 +122,16 @@ SYM_FUNC_END(srso_safe_ret_alias)
.section .text.__x86.return_thunk
+SYM_CODE_START(srso_alias_return_thunk)
+ UNWIND_HINT_FUNC
+ ANNOTATE_NOENDBR
+ call srso_safe_ret_alias
+ ud2
+SYM_CODE_END(srso_alias_return_thunk)
+
/*
* Safety details here pertain to the AMD Zen{1,2} microarchitecture:
- * 1) The RET at __x86_return_thunk must be on a 64 byte boundary, for
+ * 1) The RET at zen_return_thunk must be on a 64 byte boundary, for
* alignment within the BTB.
* 2) The instruction at zen_untrain_ret must contain, and not
* end with, the 0xc3 byte of the RET.
@@ -127,7 +139,7 @@ SYM_FUNC_END(srso_safe_ret_alias)
* from re-poisioning the BTB prediction.
*/
.align 64
- .skip 64 - (__ret - zen_untrain_ret), 0xcc
+ .skip 64 - (zen_return_thunk - zen_untrain_ret), 0xcc
SYM_START(zen_untrain_ret, SYM_L_GLOBAL, SYM_A_NONE)
ANNOTATE_NOENDBR
/*
@@ -135,16 +147,16 @@ SYM_START(zen_untrain_ret, SYM_L_GLOBAL,
*
* TEST $0xcc, %bl
* LFENCE
- * JMP __x86_return_thunk
+ * JMP zen_return_thunk
*
* Executing the TEST instruction has a side effect of evicting any BTB
* prediction (potentially attacker controlled) attached to the RET, as
- * __x86_return_thunk + 1 isn't an instruction boundary at the moment.
+ * zen_return_thunk + 1 isn't an instruction boundary at the moment.
*/
.byte 0xf6
/*
- * As executed from __x86_return_thunk, this is a plain RET.
+ * As executed from zen_return_thunk, this is a plain RET.
*
* As part of the TEST above, RET is the ModRM byte, and INT3 the imm8.
*
@@ -156,13 +168,13 @@ SYM_START(zen_untrain_ret, SYM_L_GLOBAL,
* With SMT enabled and STIBP active, a sibling thread cannot poison
* RET's prediction to a type of its choice, but can evict the
* prediction due to competitive sharing. If the prediction is
- * evicted, __x86_return_thunk will suffer Straight Line Speculation
+ * evicted, zen_return_thunk will suffer Straight Line Speculation
* which will be contained safely by the INT3.
*/
-SYM_INNER_LABEL(__ret, SYM_L_GLOBAL)
+SYM_INNER_LABEL(zen_return_thunk, SYM_L_GLOBAL)
ret
int3
-SYM_CODE_END(__ret)
+SYM_CODE_END(zen_return_thunk)
/*
* Ensure the TEST decoding / BTB invalidation is complete.
@@ -173,7 +185,7 @@ SYM_CODE_END(__ret)
* Jump back and execute the RET in the middle of the TEST instruction.
* INT3 is for SLS protection.
*/
- jmp __ret
+ jmp zen_return_thunk
int3
SYM_FUNC_END(zen_untrain_ret)
__EXPORT_THUNK(zen_untrain_ret)
@@ -194,12 +206,19 @@ SYM_START(srso_untrain_ret, SYM_L_GLOBAL
ANNOTATE_NOENDBR
.byte 0x48, 0xb8
+/*
+ * This forces the function return instruction to speculate into a trap
+ * (UD2 in srso_return_thunk() below). This RET will then mispredict
+ * and execution will continue at the return site read from the top of
+ * the stack.
+ */
SYM_INNER_LABEL(srso_safe_ret, SYM_L_GLOBAL)
add $8, %_ASM_SP
ret
int3
int3
int3
+ /* end of movabs */
lfence
call srso_safe_ret
ud2
@@ -207,12 +226,19 @@ SYM_CODE_END(srso_safe_ret)
SYM_FUNC_END(srso_untrain_ret)
__EXPORT_THUNK(srso_untrain_ret)
-SYM_CODE_START(__x86_return_thunk)
+SYM_CODE_START(srso_return_thunk)
UNWIND_HINT_FUNC
ANNOTATE_NOENDBR
- ALTERNATIVE_2 "jmp __ret", "call srso_safe_ret", X86_FEATURE_SRSO, \
- "call srso_safe_ret_alias", X86_FEATURE_SRSO_ALIAS
+ call srso_safe_ret
ud2
+SYM_CODE_END(srso_return_thunk)
+
+SYM_CODE_START(__x86_return_thunk)
+ UNWIND_HINT_FUNC
+ ANNOTATE_NOENDBR
+ ANNOTATE_UNRET_SAFE
+ ret
+ int3
SYM_CODE_END(__x86_return_thunk)
EXPORT_SYMBOL(__x86_return_thunk)
--- a/tools/objtool/arch/x86/decode.c
+++ b/tools/objtool/arch/x86/decode.c
@@ -799,5 +799,5 @@ bool arch_is_rethunk(struct symbol *sym)
return !strcmp(sym->name, "__x86_return_thunk") ||
!strcmp(sym->name, "srso_untrain_ret") ||
!strcmp(sym->name, "srso_safe_ret") ||
- !strcmp(sym->name, "__ret");
+ !strcmp(sym->name, "zen_return_thunk");
}
next prev parent reply other threads:[~2023-08-24 14:15 UTC|newest]
Thread overview: 36+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-08-24 14:14 [PATCH 6.1 00/15] 6.1.48-rc1 review Greg Kroah-Hartman
2023-08-24 14:14 ` [PATCH 6.1 01/15] x86/cpu: Fix __x86_return_thunk symbol type Greg Kroah-Hartman
2023-08-24 14:14 ` [PATCH 6.1 02/15] x86/cpu: Fix up srso_safe_ret() and __x86_return_thunk() Greg Kroah-Hartman
2023-08-24 14:14 ` [PATCH 6.1 03/15] x86/alternative: Make custom return thunk unconditional Greg Kroah-Hartman
2023-08-24 14:15 ` Greg Kroah-Hartman [this message]
2023-08-24 14:15 ` [PATCH 6.1 05/15] x86/cpu: Rename original retbleed methods Greg Kroah-Hartman
2023-08-24 14:15 ` [PATCH 6.1 06/15] x86/cpu: Rename srso_(.*)_alias to srso_alias_\1 Greg Kroah-Hartman
2023-08-24 14:15 ` [PATCH 6.1 07/15] x86/cpu: Cleanup the untrain mess Greg Kroah-Hartman
2023-08-24 14:15 ` [PATCH 6.1 08/15] x86/srso: Explain the untraining sequences a bit more Greg Kroah-Hartman
2023-08-24 14:15 ` [PATCH 6.1 09/15] x86/static_call: Fix __static_call_fixup() Greg Kroah-Hartman
2023-08-24 14:15 ` [PATCH 6.1 10/15] x86/retpoline: Dont clobber RFLAGS during srso_safe_ret() Greg Kroah-Hartman
2023-08-24 14:15 ` [PATCH 6.1 11/15] x86/CPU/AMD: Fix the DIV(0) initial fix attempt Greg Kroah-Hartman
2023-08-24 14:15 ` [PATCH 6.1 12/15] x86/srso: Disable the mitigation on unaffected configurations Greg Kroah-Hartman
2023-08-24 14:15 ` [PATCH 6.1 13/15] x86/retpoline,kprobes: Fix position of thunk sections with CONFIG_LTO_CLANG Greg Kroah-Hartman
2023-08-24 14:15 ` [PATCH 6.1 14/15] objtool/x86: Fixup frame-pointer vs rethunk Greg Kroah-Hartman
2023-08-24 14:15 ` [PATCH 6.1 15/15] x86/srso: Correct the mitigation status when SMT is disabled Greg Kroah-Hartman
2023-08-24 21:31 ` [PATCH 6.1 00/15] 6.1.48-rc1 review Florian Fainelli
2023-08-25 3:05 ` Florian Fainelli
2023-08-25 1:30 ` SeongJae Park
2023-08-25 2:40 ` Joel Fernandes
2023-08-25 7:05 ` Naresh Kamboju
2023-08-25 7:15 ` Harshit Mogalapalli
2023-08-25 7:45 ` Christian Brauner
2023-08-25 8:10 ` Greg Kroah-Hartman
2023-08-25 8:48 ` Naresh Kamboju
2023-08-25 16:29 ` Harshit Mogalapalli
2023-08-25 9:33 ` Naresh Kamboju
2023-08-25 9:26 ` Sudip Mukherjee (Codethink)
2023-08-26 8:45 ` Salvatore Bonaccorso
2023-08-25 9:40 ` Naresh Kamboju
2023-08-25 10:15 ` Jon Hunter
2023-08-25 12:16 ` Conor Dooley
2023-08-25 12:33 ` Takeshi Ogasawara
2023-08-25 15:40 ` Guenter Roeck
2023-08-25 18:12 ` Shuah Khan
2023-08-26 1:23 ` Bagas Sanjaya
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20230824141447.392496309@linuxfoundation.org \
--to=gregkh@linuxfoundation.org \
--cc=bp@alien8.de \
--cc=patches@lists.linux.dev \
--cc=peterz@infradead.org \
--cc=stable@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).