This is the start of the stable review cycle for the 6.1.48 release. There are 15 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
Responses should be made by Sat, 26 Aug 2023 14:14:28 +0000. Anything received after that time might be too late.
The whole patch series can be found in one patch at: https://www.kernel.org/pub/linux/kernel/v6.x/stable-review/patch-6.1.48-rc1.... or in the git tree and branch at: git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-6.1.y and the diffstat can be found below.
thanks,
greg k-h
------------- Pseudo-Shortlog of commits:
Greg Kroah-Hartman gregkh@linuxfoundation.org Linux 6.1.48-rc1
Borislav Petkov (AMD) bp@alien8.de x86/srso: Correct the mitigation status when SMT is disabled
Peter Zijlstra peterz@infradead.org objtool/x86: Fixup frame-pointer vs rethunk
Petr Pavlu petr.pavlu@suse.com x86/retpoline,kprobes: Fix position of thunk sections with CONFIG_LTO_CLANG
Borislav Petkov (AMD) bp@alien8.de x86/srso: Disable the mitigation on unaffected configurations
Borislav Petkov (AMD) bp@alien8.de x86/CPU/AMD: Fix the DIV(0) initial fix attempt
Sean Christopherson seanjc@google.com x86/retpoline: Don't clobber RFLAGS during srso_safe_ret()
Peter Zijlstra peterz@infradead.org x86/static_call: Fix __static_call_fixup()
Borislav Petkov (AMD) bp@alien8.de x86/srso: Explain the untraining sequences a bit more
Peter Zijlstra peterz@infradead.org x86/cpu: Cleanup the untrain mess
Peter Zijlstra peterz@infradead.org x86/cpu: Rename srso_(.*)_alias to srso_alias_\1
Peter Zijlstra peterz@infradead.org x86/cpu: Rename original retbleed methods
Peter Zijlstra peterz@infradead.org x86/cpu: Clean up SRSO return thunk mess
Peter Zijlstra peterz@infradead.org x86/alternative: Make custom return thunk unconditional
Peter Zijlstra peterz@infradead.org x86/cpu: Fix up srso_safe_ret() and __x86_return_thunk()
Peter Zijlstra peterz@infradead.org x86/cpu: Fix __x86_return_thunk symbol type
-------------
Diffstat:
Documentation/admin-guide/hw-vuln/srso.rst | 4 +- Makefile | 4 +- arch/x86/include/asm/entry-common.h | 1 + arch/x86/include/asm/nospec-branch.h | 28 +++--- arch/x86/kernel/cpu/amd.c | 1 + arch/x86/kernel/cpu/bugs.c | 28 +++++- arch/x86/kernel/static_call.c | 13 +++ arch/x86/kernel/traps.c | 2 - arch/x86/kernel/vmlinux.lds.S | 20 ++-- arch/x86/kvm/svm/svm.c | 2 + arch/x86/lib/retpoline.S | 141 ++++++++++++++++++++--------- tools/objtool/arch/x86/decode.c | 2 +- tools/objtool/check.c | 21 +++-- 13 files changed, 182 insertions(+), 85 deletions(-)
From: Peter Zijlstra peterz@infradead.org
commit 77f67119004296a9b2503b377d610e08b08afc2a upstream.
Commit
fb3bd914b3ec ("x86/srso: Add a Speculative RAS Overflow mitigation")
reimplemented __x86_return_thunk with a mix of SYM_FUNC_START and SYM_CODE_END, this is not a sane combination.
Since nothing should ever actually 'CALL' this, make it consistently CODE.
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.571027074@infradead.org Signed-off-by: Greg Kroah-Hartman gregkh@linuxfoundation.org --- arch/x86/lib/retpoline.S | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-)
--- a/arch/x86/lib/retpoline.S +++ b/arch/x86/lib/retpoline.S @@ -207,7 +207,9 @@ SYM_CODE_END(srso_safe_ret) SYM_FUNC_END(srso_untrain_ret) __EXPORT_THUNK(srso_untrain_ret)
-SYM_FUNC_START(__x86_return_thunk) +SYM_CODE_START(__x86_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 int3
From: Peter Zijlstra peterz@infradead.org
commit af023ef335f13c8b579298fc432daeef609a9e60 upstream.
vmlinux.o: warning: objtool: srso_untrain_ret() falls through to next function __x86_return_skl() vmlinux.o: warning: objtool: __x86_return_thunk() falls through to next function __x86_return_skl()
This is because these functions (can) end with CALL, which objtool does not consider a terminating instruction. Therefore, replace the INT3 instruction (which is a non-fatal trap) with UD2 (which is a fatal-trap).
This indicates execution will not continue past this point.
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.637802730@infradead.org Signed-off-by: Greg Kroah-Hartman gregkh@linuxfoundation.org --- arch/x86/lib/retpoline.S | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
--- a/arch/x86/lib/retpoline.S +++ b/arch/x86/lib/retpoline.S @@ -202,7 +202,7 @@ SYM_INNER_LABEL(srso_safe_ret, SYM_L_GLO int3 lfence call srso_safe_ret - int3 + ud2 SYM_CODE_END(srso_safe_ret) SYM_FUNC_END(srso_untrain_ret) __EXPORT_THUNK(srso_untrain_ret) @@ -212,7 +212,7 @@ SYM_CODE_START(__x86_return_thunk) ANNOTATE_NOENDBR ALTERNATIVE_2 "jmp __ret", "call srso_safe_ret", X86_FEATURE_SRSO, \ "call srso_safe_ret_alias", X86_FEATURE_SRSO_ALIAS - int3 + ud2 SYM_CODE_END(__x86_return_thunk) EXPORT_SYMBOL(__x86_return_thunk)
From: Peter Zijlstra peterz@infradead.org
commit 095b8303f3835c68ac4a8b6d754ca1c3b6230711 upstream.
There is infrastructure to rewrite return thunks to point to any random thunk one desires, unwrap that from CALL_THUNKS, which up to now was the sole user of that.
[ bp: Make the thunks visible on 32-bit and add ifdeffery for the 32-bit builds. ]
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.775293785@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 | 2 ++ 2 files changed, 7 insertions(+)
--- a/arch/x86/include/asm/nospec-branch.h +++ b/arch/x86/include/asm/nospec-branch.h @@ -210,7 +210,12 @@ typedef u8 retpoline_thunk_t[RETPOLINE_THUNK_SIZE]; extern retpoline_thunk_t __x86_indirect_thunk_array[];
+#ifdef CONFIG_RETHUNK extern void __x86_return_thunk(void); +#else +static inline void __x86_return_thunk(void) {} +#endif + extern void zen_untrain_ret(void); extern void srso_untrain_ret(void); extern void srso_untrain_ret_alias(void); --- a/arch/x86/kernel/cpu/bugs.c +++ b/arch/x86/kernel/cpu/bugs.c @@ -62,6 +62,8 @@ EXPORT_SYMBOL_GPL(x86_pred_cmd);
static DEFINE_MUTEX(spec_ctrl_mutex);
+void (*x86_return_thunk)(void) __ro_after_init = &__x86_return_thunk; + /* Update SPEC_CTRL MSR and its cached copy unconditionally */ static void update_spec_ctrl(u64 val) {
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"); }
From: Peter Zijlstra peterz@infradead.org
commit d025b7bac07a6e90b6b98b487f88854ad9247c39 upstream.
Rename the original retbleed return thunk and untrain_ret to retbleed_return_thunk() and retbleed_untrain_ret().
No functional changes.
Suggested-by: Josh Poimboeuf jpoimboe@kernel.org 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.909378169@infradead.org Signed-off-by: Greg Kroah-Hartman gregkh@linuxfoundation.org --- arch/x86/include/asm/nospec-branch.h | 8 ++++---- arch/x86/kernel/cpu/bugs.c | 2 +- arch/x86/kernel/vmlinux.lds.S | 2 +- arch/x86/lib/retpoline.S | 30 +++++++++++++++--------------- tools/objtool/arch/x86/decode.c | 2 +- tools/objtool/check.c | 2 +- 6 files changed, 23 insertions(+), 23 deletions(-)
--- a/arch/x86/include/asm/nospec-branch.h +++ b/arch/x86/include/asm/nospec-branch.h @@ -168,7 +168,7 @@ .endm
#ifdef CONFIG_CPU_UNRET_ENTRY -#define CALL_ZEN_UNTRAIN_RET "call zen_untrain_ret" +#define CALL_ZEN_UNTRAIN_RET "call retbleed_untrain_ret" #else #define CALL_ZEN_UNTRAIN_RET "" #endif @@ -178,7 +178,7 @@ * return thunk isn't mapped into the userspace tables (then again, AMD * typically has NO_MELTDOWN). * - * While zen_untrain_ret() doesn't clobber anything but requires stack, + * While retbleed_untrain_ret() doesn't clobber anything but requires stack, * entry_ibpb() will clobber AX, CX, DX. * * As such, this must be placed after every *SWITCH_TO_KERNEL_CR3 at a point @@ -216,11 +216,11 @@ extern void __x86_return_thunk(void); static inline void __x86_return_thunk(void) {} #endif
-extern void zen_return_thunk(void); +extern void retbleed_return_thunk(void); extern void srso_return_thunk(void); extern void srso_alias_return_thunk(void);
-extern void zen_untrain_ret(void); +extern void retbleed_untrain_ret(void); extern void srso_untrain_ret(void); extern void srso_untrain_ret_alias(void);
--- a/arch/x86/kernel/cpu/bugs.c +++ b/arch/x86/kernel/cpu/bugs.c @@ -1021,7 +1021,7 @@ do_cmd_auto: setup_force_cpu_cap(X86_FEATURE_UNRET);
if (IS_ENABLED(CONFIG_RETHUNK)) - x86_return_thunk = zen_return_thunk; + x86_return_thunk = retbleed_return_thunk;
if (boot_cpu_data.x86_vendor != X86_VENDOR_AMD && boot_cpu_data.x86_vendor != X86_VENDOR_HYGON) --- a/arch/x86/kernel/vmlinux.lds.S +++ b/arch/x86/kernel/vmlinux.lds.S @@ -508,7 +508,7 @@ INIT_PER_CPU(irq_stack_backing_store); #endif
#ifdef CONFIG_RETHUNK -. = ASSERT((zen_return_thunk & 0x3f) == 0, "zen_return_thunk not cacheline-aligned"); +. = ASSERT((retbleed_return_thunk & 0x3f) == 0, "retbleed_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 @@ -131,32 +131,32 @@ SYM_CODE_END(srso_alias_return_thunk)
/* * Safety details here pertain to the AMD Zen{1,2} microarchitecture: - * 1) The RET at zen_return_thunk must be on a 64 byte boundary, for + * 1) The RET at retbleed_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 + * 2) The instruction at retbleed_untrain_ret must contain, and not * end with, the 0xc3 byte of the RET. * 3) STIBP must be enabled, or SMT disabled, to prevent the sibling thread * from re-poisioning the BTB prediction. */ .align 64 - .skip 64 - (zen_return_thunk - zen_untrain_ret), 0xcc -SYM_START(zen_untrain_ret, SYM_L_GLOBAL, SYM_A_NONE) + .skip 64 - (retbleed_return_thunk - retbleed_untrain_ret), 0xcc +SYM_START(retbleed_untrain_ret, SYM_L_GLOBAL, SYM_A_NONE) ANNOTATE_NOENDBR /* - * As executed from zen_untrain_ret, this is: + * As executed from retbleed_untrain_ret, this is: * * TEST $0xcc, %bl * LFENCE - * JMP zen_return_thunk + * JMP retbleed_return_thunk * * Executing the TEST instruction has a side effect of evicting any BTB * prediction (potentially attacker controlled) attached to the RET, as - * zen_return_thunk + 1 isn't an instruction boundary at the moment. + * retbleed_return_thunk + 1 isn't an instruction boundary at the moment. */ .byte 0xf6
/* - * As executed from zen_return_thunk, this is a plain RET. + * As executed from retbleed_return_thunk, this is a plain RET. * * As part of the TEST above, RET is the ModRM byte, and INT3 the imm8. * @@ -168,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, zen_return_thunk will suffer Straight Line Speculation + * evicted, retbleed_return_thunk will suffer Straight Line Speculation * which will be contained safely by the INT3. */ -SYM_INNER_LABEL(zen_return_thunk, SYM_L_GLOBAL) +SYM_INNER_LABEL(retbleed_return_thunk, SYM_L_GLOBAL) ret int3 -SYM_CODE_END(zen_return_thunk) +SYM_CODE_END(retbleed_return_thunk)
/* * Ensure the TEST decoding / BTB invalidation is complete. @@ -185,13 +185,13 @@ SYM_CODE_END(zen_return_thunk) * Jump back and execute the RET in the middle of the TEST instruction. * INT3 is for SLS protection. */ - jmp zen_return_thunk + jmp retbleed_return_thunk int3 -SYM_FUNC_END(zen_untrain_ret) -__EXPORT_THUNK(zen_untrain_ret) +SYM_FUNC_END(retbleed_untrain_ret) +__EXPORT_THUNK(retbleed_untrain_ret)
/* - * SRSO untraining sequence for Zen1/2, similar to zen_untrain_ret() + * SRSO untraining sequence for Zen1/2, similar to retbleed_untrain_ret() * above. On kernel entry, srso_untrain_ret() is executed which is a * * movabs $0xccccccc308c48348,%rax --- 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, "zen_return_thunk"); + !strcmp(sym->name, "retbleed_return_thunk"); } --- a/tools/objtool/check.c +++ b/tools/objtool/check.c @@ -1430,7 +1430,7 @@ static int add_jump_destinations(struct struct symbol *sym = find_symbol_by_offset(dest_sec, dest_off);
/* - * This is a special case for zen_untrain_ret(). + * This is a special case for retbleed_untrain_ret(). * It jumps to __x86_return_thunk(), but objtool * can't find the thunk's starting RET * instruction, because the RET is also in the
From: Peter Zijlstra peterz@infradead.org
commit 42be649dd1f2eee6b1fb185f1a231b9494cf095f upstream.
For a more consistent namespace.
[ bp: Fixup names in the doc too. ]
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.976236447@infradead.org Signed-off-by: Greg Kroah-Hartman gregkh@linuxfoundation.org --- Documentation/admin-guide/hw-vuln/srso.rst | 4 ++-- arch/x86/include/asm/nospec-branch.h | 4 ++-- arch/x86/kernel/vmlinux.lds.S | 8 ++++---- arch/x86/lib/retpoline.S | 26 +++++++++++++------------- 4 files changed, 21 insertions(+), 21 deletions(-)
--- a/Documentation/admin-guide/hw-vuln/srso.rst +++ b/Documentation/admin-guide/hw-vuln/srso.rst @@ -124,8 +124,8 @@ sequence. To ensure the safety of this mitigation, the kernel must ensure that the safe return sequence is itself free from attacker interference. In Zen3 and Zen4, this is accomplished by creating a BTB alias between the -untraining function srso_untrain_ret_alias() and the safe return -function srso_safe_ret_alias() which results in evicting a potentially +untraining function srso_alias_untrain_ret() and the safe return +function srso_alias_safe_ret() which results in evicting a potentially poisoned BTB entry and using that safe one for all function returns.
In older Zen1 and Zen2, this is accomplished using a reinterpretation --- a/arch/x86/include/asm/nospec-branch.h +++ b/arch/x86/include/asm/nospec-branch.h @@ -195,7 +195,7 @@
#ifdef CONFIG_CPU_SRSO ALTERNATIVE_2 "", "call srso_untrain_ret", X86_FEATURE_SRSO, \ - "call srso_untrain_ret_alias", X86_FEATURE_SRSO_ALIAS + "call srso_alias_untrain_ret", X86_FEATURE_SRSO_ALIAS #endif .endm
@@ -222,7 +222,7 @@ extern void srso_alias_return_thunk(void
extern void retbleed_untrain_ret(void); extern void srso_untrain_ret(void); -extern void srso_untrain_ret_alias(void); +extern void srso_alias_untrain_ret(void);
extern void entry_ibpb(void);
--- a/arch/x86/kernel/vmlinux.lds.S +++ b/arch/x86/kernel/vmlinux.lds.S @@ -141,10 +141,10 @@ SECTIONS
#ifdef CONFIG_CPU_SRSO /* - * See the comment above srso_untrain_ret_alias()'s + * See the comment above srso_alias_untrain_ret()'s * definition. */ - . = srso_untrain_ret_alias | (1 << 2) | (1 << 8) | (1 << 14) | (1 << 20); + . = srso_alias_untrain_ret | (1 << 2) | (1 << 8) | (1 << 14) | (1 << 20); *(.text.__x86.rethunk_safe) #endif ALIGN_ENTRY_TEXT_END @@ -523,8 +523,8 @@ INIT_PER_CPU(irq_stack_backing_store); * Instead do: (A | B) - (A & B) in order to compute the XOR * of the two function addresses: */ -. = ASSERT(((ABSOLUTE(srso_untrain_ret_alias) | srso_safe_ret_alias) - - (ABSOLUTE(srso_untrain_ret_alias) & srso_safe_ret_alias)) == ((1 << 2) | (1 << 8) | (1 << 14) | (1 << 20)), +. = ASSERT(((ABSOLUTE(srso_alias_untrain_ret) | srso_alias_safe_ret) - + (ABSOLUTE(srso_alias_untrain_ret) & srso_alias_safe_ret)) == ((1 << 2) | (1 << 8) | (1 << 14) | (1 << 20)), "SRSO function pair won't alias"); #endif
--- a/arch/x86/lib/retpoline.S +++ b/arch/x86/lib/retpoline.S @@ -76,56 +76,56 @@ SYM_CODE_END(__x86_indirect_thunk_array) #ifdef CONFIG_RETHUNK
/* - * srso_untrain_ret_alias() and srso_safe_ret_alias() are placed at + * srso_alias_untrain_ret() and srso_alias_safe_ret() are placed at * special addresses: * - * - srso_untrain_ret_alias() is 2M aligned - * - srso_safe_ret_alias() is also in the same 2M page but bits 2, 8, 14 + * - srso_alias_untrain_ret() is 2M aligned + * - srso_alias_safe_ret() is also in the same 2M page but bits 2, 8, 14 * and 20 in its virtual address are set (while those bits in the - * srso_untrain_ret_alias() function are cleared). + * srso_alias_untrain_ret() function are cleared). * * This guarantees that those two addresses will alias in the branch * target buffer of Zen3/4 generations, leading to any potential * poisoned entries at that BTB slot to get evicted. * - * As a result, srso_safe_ret_alias() becomes a safe return. + * As a result, srso_alias_safe_ret() becomes a safe return. */ #ifdef CONFIG_CPU_SRSO .section .text.__x86.rethunk_untrain
-SYM_START(srso_untrain_ret_alias, SYM_L_GLOBAL, SYM_A_NONE) +SYM_START(srso_alias_untrain_ret, SYM_L_GLOBAL, SYM_A_NONE) UNWIND_HINT_FUNC ANNOTATE_NOENDBR ASM_NOP2 lfence jmp srso_alias_return_thunk -SYM_FUNC_END(srso_untrain_ret_alias) -__EXPORT_THUNK(srso_untrain_ret_alias) +SYM_FUNC_END(srso_alias_untrain_ret) +__EXPORT_THUNK(srso_alias_untrain_ret)
.section .text.__x86.rethunk_safe #else /* dummy definition for alternatives */ -SYM_START(srso_untrain_ret_alias, SYM_L_GLOBAL, SYM_A_NONE) +SYM_START(srso_alias_untrain_ret, SYM_L_GLOBAL, SYM_A_NONE) ANNOTATE_UNRET_SAFE ret int3 -SYM_FUNC_END(srso_untrain_ret_alias) +SYM_FUNC_END(srso_alias_untrain_ret) #endif
-SYM_START(srso_safe_ret_alias, SYM_L_GLOBAL, SYM_A_NONE) +SYM_START(srso_alias_safe_ret, SYM_L_GLOBAL, SYM_A_NONE) add $8, %_ASM_SP UNWIND_HINT_FUNC ANNOTATE_UNRET_SAFE ret int3 -SYM_FUNC_END(srso_safe_ret_alias) +SYM_FUNC_END(srso_alias_safe_ret)
.section .text.__x86.return_thunk
SYM_CODE_START(srso_alias_return_thunk) UNWIND_HINT_FUNC ANNOTATE_NOENDBR - call srso_safe_ret_alias + call srso_alias_safe_ret ud2 SYM_CODE_END(srso_alias_return_thunk)
From: Peter Zijlstra peterz@infradead.org
commit e7c25c441e9e0fa75b4c83e0b26306b702cfe90d upstream.
Since there can only be one active return_thunk, there only needs be one (matching) untrain_ret. It fundamentally doesn't make sense to allow multiple untrain_ret at the same time.
Fold all the 3 different untrain methods into a single (temporary) helper stub.
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/20230814121149.042774962@infradead.org Signed-off-by: Greg Kroah-Hartman gregkh@linuxfoundation.org --- arch/x86/include/asm/nospec-branch.h | 12 ++++-------- arch/x86/kernel/cpu/bugs.c | 1 + arch/x86/lib/retpoline.S | 7 +++++++ 3 files changed, 12 insertions(+), 8 deletions(-)
--- a/arch/x86/include/asm/nospec-branch.h +++ b/arch/x86/include/asm/nospec-branch.h @@ -168,9 +168,9 @@ .endm
#ifdef CONFIG_CPU_UNRET_ENTRY -#define CALL_ZEN_UNTRAIN_RET "call retbleed_untrain_ret" +#define CALL_UNTRAIN_RET "call entry_untrain_ret" #else -#define CALL_ZEN_UNTRAIN_RET "" +#define CALL_UNTRAIN_RET "" #endif
/* @@ -189,14 +189,9 @@ defined(CONFIG_CPU_SRSO) ANNOTATE_UNRET_END ALTERNATIVE_2 "", \ - CALL_ZEN_UNTRAIN_RET, X86_FEATURE_UNRET, \ + CALL_UNTRAIN_RET, X86_FEATURE_UNRET, \ "call entry_ibpb", X86_FEATURE_ENTRY_IBPB #endif - -#ifdef CONFIG_CPU_SRSO - ALTERNATIVE_2 "", "call srso_untrain_ret", X86_FEATURE_SRSO, \ - "call srso_alias_untrain_ret", X86_FEATURE_SRSO_ALIAS -#endif .endm
#else /* __ASSEMBLY__ */ @@ -224,6 +219,7 @@ extern void retbleed_untrain_ret(void); extern void srso_untrain_ret(void); extern void srso_alias_untrain_ret(void);
+extern void entry_untrain_ret(void); extern void entry_ibpb(void);
#ifdef CONFIG_RETPOLINE --- a/arch/x86/kernel/cpu/bugs.c +++ b/arch/x86/kernel/cpu/bugs.c @@ -2429,6 +2429,7 @@ static void __init srso_select_mitigatio * like ftrace, static_call, etc. */ setup_force_cpu_cap(X86_FEATURE_RETHUNK); + setup_force_cpu_cap(X86_FEATURE_UNRET);
if (boot_cpu_data.x86 == 0x19) { setup_force_cpu_cap(X86_FEATURE_SRSO_ALIAS); --- a/arch/x86/lib/retpoline.S +++ b/arch/x86/lib/retpoline.S @@ -233,6 +233,13 @@ SYM_CODE_START(srso_return_thunk) ud2 SYM_CODE_END(srso_return_thunk)
+SYM_FUNC_START(entry_untrain_ret) + ALTERNATIVE_2 "jmp retbleed_untrain_ret", \ + "jmp srso_untrain_ret", X86_FEATURE_SRSO, \ + "jmp srso_alias_untrain_ret", X86_FEATURE_SRSO_ALIAS +SYM_FUNC_END(entry_untrain_ret) +__EXPORT_THUNK(entry_untrain_ret) + SYM_CODE_START(__x86_return_thunk) UNWIND_HINT_FUNC ANNOTATE_NOENDBR
From: Borislav Petkov (AMD) bp@alien8.de
commit 9dbd23e42ff0b10c9b02c9e649c76e5228241a8e upstream.
The goal is to eventually have a proper documentation about all this.
Signed-off-by: Borislav Petkov (AMD) bp@alien8.de Link: https://lore.kernel.org/r/20230814164447.GFZNpZ/64H4lENIe94@fat_crate.local Signed-off-by: Greg Kroah-Hartman gregkh@linuxfoundation.org --- arch/x86/lib/retpoline.S | 19 +++++++++++++++++++ 1 file changed, 19 insertions(+)
--- a/arch/x86/lib/retpoline.S +++ b/arch/x86/lib/retpoline.S @@ -130,6 +130,25 @@ SYM_CODE_START(srso_alias_return_thunk) SYM_CODE_END(srso_alias_return_thunk)
/* + * Some generic notes on the untraining sequences: + * + * They are interchangeable when it comes to flushing potentially wrong + * RET predictions from the BTB. + * + * The SRSO Zen1/2 (MOVABS) untraining sequence is longer than the + * Retbleed sequence because the return sequence done there + * (srso_safe_ret()) is longer and the return sequence must fully nest + * (end before) the untraining sequence. Therefore, the untraining + * sequence must fully overlap the return sequence. + * + * Regarding alignment - the instructions which need to be untrained, + * must all start at a cacheline boundary for Zen1/2 generations. That + * is, instruction sequences starting at srso_safe_ret() and + * the respective instruction sequences at retbleed_return_thunk() + * must start at a cacheline boundary. + */ + +/* * Safety details here pertain to the AMD Zen{1,2} microarchitecture: * 1) The RET at retbleed_return_thunk must be on a 64 byte boundary, for * alignment within the BTB.
From: Peter Zijlstra peterz@infradead.org
commit 54097309620ef0dc2d7083783dc521c6a5fef957 upstream.
Christian reported spurious module load crashes after some of Song's module memory layout patches.
Turns out that if the very last instruction on the very last page of the module is a 'JMP __x86_return_thunk' then __static_call_fixup() will trip a fault and die.
And while the module rework made this slightly more likely to happen, it's always been possible.
Fixes: ee88d363d156 ("x86,static_call: Use alternative RET encoding") Reported-by: Christian Bricart christian@bricart.de Signed-off-by: Peter Zijlstra (Intel) peterz@infradead.org Acked-by: Josh Poimboeuf jpoimboe@kernel.org Link: https://lkml.kernel.org/r/20230816104419.GA982867@hirez.programming.kicks-as... Signed-off-by: Greg Kroah-Hartman gregkh@linuxfoundation.org --- arch/x86/kernel/static_call.c | 13 +++++++++++++ 1 file changed, 13 insertions(+)
--- a/arch/x86/kernel/static_call.c +++ b/arch/x86/kernel/static_call.c @@ -184,6 +184,19 @@ EXPORT_SYMBOL_GPL(arch_static_call_trans */ bool __static_call_fixup(void *tramp, u8 op, void *dest) { + unsigned long addr = (unsigned long)tramp; + /* + * Not all .return_sites are a static_call trampoline (most are not). + * Check if the 3 bytes after the return are still kernel text, if not, + * then this definitely is not a trampoline and we need not worry + * further. + * + * This avoids the memcmp() below tripping over pagefaults etc.. + */ + if (((addr >> PAGE_SHIFT) != ((addr + 7) >> PAGE_SHIFT)) && + !kernel_text_address(addr + 7)) + return false; + if (memcmp(tramp+5, tramp_ud, 3)) { /* Not a trampoline site, not our problem. */ return false;
From: Sean Christopherson seanjc@google.com
commit ba5ca5e5e6a1d55923e88b4a83da452166f5560e upstream.
Use LEA instead of ADD when adjusting %rsp in srso_safe_ret{,_alias}() so as to avoid clobbering flags. Drop one of the INT3 instructions to account for the LEA consuming one more byte than the ADD.
KVM's emulator makes indirect calls into a jump table of sorts, where the destination of each call is a small blob of code that performs fast emulation by executing the target instruction with fixed operands.
E.g. to emulate ADC, fastop() invokes adcb_al_dl():
adcb_al_dl: <+0>: adc %dl,%al <+2>: jmp <__x86_return_thunk>
A major motivation for doing fast emulation is to leverage the CPU to handle consumption and manipulation of arithmetic flags, i.e. RFLAGS is both an input and output to the target of the call. fastop() collects the RFLAGS result by pushing RFLAGS onto the stack and popping them back into a variable (held in %rdi in this case):
asm("push %[flags]; popf; " CALL_NOSPEC " ; pushf; pop %[flags]\n"
<+71>: mov 0xc0(%r8),%rdx <+78>: mov 0x100(%r8),%rcx <+85>: push %rdi <+86>: popf <+87>: call *%rsi <+89>: nop <+90>: nop <+91>: nop <+92>: pushf <+93>: pop %rdi
and then propagating the arithmetic flags into the vCPU's emulator state:
ctxt->eflags = (ctxt->eflags & ~EFLAGS_MASK) | (flags & EFLAGS_MASK);
<+64>: and $0xfffffffffffff72a,%r9 <+94>: and $0x8d5,%edi <+109>: or %rdi,%r9 <+122>: mov %r9,0x10(%r8)
The failures can be most easily reproduced by running the "emulator" test in KVM-Unit-Tests.
If you're feeling a bit of deja vu, see commit b63f20a778c8 ("x86/retpoline: Don't clobber RFLAGS during CALL_NOSPEC on i386").
In addition, this breaks booting of clang-compiled guest on a gcc-compiled host where the host contains the %rsp-modifying SRSO mitigations.
[ bp: Massage commit message, extend, remove addresses. ]
Fixes: fb3bd914b3ec ("x86/srso: Add a Speculative RAS Overflow mitigation") Closes: https://lore.kernel.org/all/de474347-122d-54cd-eabf-9dcc95ab9eae@amd.com Reported-by: Srikanth Aithal sraithal@amd.com Reported-by: Nathan Chancellor nathan@kernel.org Signed-off-by: Sean Christopherson seanjc@google.com Signed-off-by: Borislav Petkov (AMD) bp@alien8.de Tested-by: Nathan Chancellor nathan@kernel.org Cc: stable@vger.kernel.org Link: https://lore.kernel.org/20230810013334.GA5354@dev-arch.thelio-3990X/ Link: https://lore.kernel.org/r/20230811155255.250835-1-seanjc@google.com Signed-off-by: Greg Kroah-Hartman gregkh@linuxfoundation.org --- arch/x86/lib/retpoline.S | 7 +++---- 1 file changed, 3 insertions(+), 4 deletions(-)
--- a/arch/x86/lib/retpoline.S +++ b/arch/x86/lib/retpoline.S @@ -113,7 +113,7 @@ SYM_FUNC_END(srso_alias_untrain_ret) #endif
SYM_START(srso_alias_safe_ret, SYM_L_GLOBAL, SYM_A_NONE) - add $8, %_ASM_SP + lea 8(%_ASM_SP), %_ASM_SP UNWIND_HINT_FUNC ANNOTATE_UNRET_SAFE ret @@ -213,7 +213,7 @@ __EXPORT_THUNK(retbleed_untrain_ret) * SRSO untraining sequence for Zen1/2, similar to retbleed_untrain_ret() * above. On kernel entry, srso_untrain_ret() is executed which is a * - * movabs $0xccccccc308c48348,%rax + * movabs $0xccccc30824648d48,%rax * * and when the return thunk executes the inner label srso_safe_ret() * later, it is a stack manipulation and a RET which is mispredicted and @@ -232,11 +232,10 @@ SYM_START(srso_untrain_ret, SYM_L_GLOBAL * the stack. */ SYM_INNER_LABEL(srso_safe_ret, SYM_L_GLOBAL) - add $8, %_ASM_SP + lea 8(%_ASM_SP), %_ASM_SP ret int3 int3 - int3 /* end of movabs */ lfence call srso_safe_ret
From: Borislav Petkov (AMD) bp@alien8.de
commit f58d6fbcb7c848b7f2469be339bc571f2e9d245b upstream.
Initially, it was thought that doing an innocuous division in the #DE handler would take care to prevent any leaking of old data from the divider but by the time the fault is raised, the speculation has already advanced too far and such data could already have been used by younger operations.
Therefore, do the innocuous division on every exit to userspace so that userspace doesn't see any potentially old data from integer divisions in kernel space.
Do the same before VMRUN too, to protect host data from leaking into the guest too.
Fixes: 77245f1c3c64 ("x86/CPU/AMD: Do not leak quotient data after a division by 0") Signed-off-by: Borislav Petkov (AMD) bp@alien8.de Cc: stable@kernel.org Link: https://lore.kernel.org/r/20230811213824.10025-1-bp@alien8.de Signed-off-by: Greg Kroah-Hartman gregkh@linuxfoundation.org --- arch/x86/include/asm/entry-common.h | 1 + arch/x86/kernel/cpu/amd.c | 1 + arch/x86/kernel/traps.c | 2 -- arch/x86/kvm/svm/svm.c | 2 ++ 4 files changed, 4 insertions(+), 2 deletions(-)
--- a/arch/x86/include/asm/entry-common.h +++ b/arch/x86/include/asm/entry-common.h @@ -92,6 +92,7 @@ static inline void arch_exit_to_user_mod static __always_inline void arch_exit_to_user_mode(void) { mds_user_clear_cpu_buffers(); + amd_clear_divider(); } #define arch_exit_to_user_mode arch_exit_to_user_mode
--- a/arch/x86/kernel/cpu/amd.c +++ b/arch/x86/kernel/cpu/amd.c @@ -1295,3 +1295,4 @@ void noinstr amd_clear_divider(void) asm volatile(ALTERNATIVE("", "div %2\n\t", X86_BUG_DIV0) :: "a" (0), "d" (0), "r" (1)); } +EXPORT_SYMBOL_GPL(amd_clear_divider); --- a/arch/x86/kernel/traps.c +++ b/arch/x86/kernel/traps.c @@ -206,8 +206,6 @@ DEFINE_IDTENTRY(exc_divide_error) { do_error_trap(regs, 0, "divide error", X86_TRAP_DE, SIGFPE, FPE_INTDIV, error_get_trap_addr(regs)); - - amd_clear_divider(); }
DEFINE_IDTENTRY(exc_overflow) --- a/arch/x86/kvm/svm/svm.c +++ b/arch/x86/kvm/svm/svm.c @@ -3947,6 +3947,8 @@ static noinstr void svm_vcpu_enter_exit(
guest_state_enter_irqoff();
+ amd_clear_divider(); + if (sev_es_guest(vcpu->kvm)) __svm_sev_es_vcpu_run(svm, spec_ctrl_intercepted); else
From: Borislav Petkov (AMD) bp@alien8.de
commit e9fbc47b818b964ddff5df5b2d5c0f5f32f4a147 upstream.
Skip the srso cmd line parsing which is not needed on Zen1/2 with SMT disabled and with the proper microcode applied (latter should be the case anyway) as those are not affected.
Fixes: 5a15d8348881 ("x86/srso: Tie SBPB bit setting to microcode patch detection") Signed-off-by: Borislav Petkov (AMD) bp@alien8.de Link: https://lore.kernel.org/r/20230813104517.3346-1-bp@alien8.de Signed-off-by: Greg Kroah-Hartman gregkh@linuxfoundation.org --- arch/x86/kernel/cpu/bugs.c | 7 ++++++- 1 file changed, 6 insertions(+), 1 deletion(-)
--- a/arch/x86/kernel/cpu/bugs.c +++ b/arch/x86/kernel/cpu/bugs.c @@ -2399,8 +2399,10 @@ static void __init srso_select_mitigatio * IBPB microcode has been applied. */ if ((boot_cpu_data.x86 < 0x19) && - (!cpu_smt_possible() || (cpu_smt_control == CPU_SMT_DISABLED))) + (!cpu_smt_possible() || (cpu_smt_control == CPU_SMT_DISABLED))) { setup_force_cpu_cap(X86_FEATURE_SRSO_NO); + return; + } }
if (retbleed_mitigation == RETBLEED_MITIGATION_IBPB) { @@ -2686,6 +2688,9 @@ static ssize_t gds_show_state(char *buf)
static ssize_t srso_show_state(char *buf) { + if (boot_cpu_has(X86_FEATURE_SRSO_NO)) + return sysfs_emit(buf, "Not affected\n"); + return sysfs_emit(buf, "%s%s\n", srso_strings[srso_mitigation], (cpu_has_ibpb_brtype_microcode() ? "" : ", no microcode"));
From: Petr Pavlu petr.pavlu@suse.com
commit 79cd2a11224eab86d6673fe8a11d2046ae9d2757 upstream.
The linker script arch/x86/kernel/vmlinux.lds.S matches the thunk sections ".text.__x86.*" from arch/x86/lib/retpoline.S as follows:
.text { [...] TEXT_TEXT [...] __indirect_thunk_start = .; *(.text.__x86.*) __indirect_thunk_end = .; [...] }
Macro TEXT_TEXT references TEXT_MAIN which normally expands to only ".text". However, with CONFIG_LTO_CLANG, TEXT_MAIN becomes ".text .text.[0-9a-zA-Z_]*" which wrongly matches also the thunk sections. The output layout is then different than expected. For instance, the currently defined range [__indirect_thunk_start, __indirect_thunk_end] becomes empty.
Prevent the problem by using ".." as the first separator, for example, ".text..__x86.indirect_thunk". This pattern is utilized by other explicit section names which start with one of the standard prefixes, such as ".text" or ".data", and that need to be individually selected in the linker script.
[ nathan: Fix conflicts with SRSO and fold in fix issue brought up by Andrew Cooper in post-review: https://lore.kernel.org/20230803230323.1478869-1-andrew.cooper3@citrix.com ]
Fixes: dc5723b02e52 ("kbuild: add support for Clang LTO") Signed-off-by: Petr Pavlu petr.pavlu@suse.com Signed-off-by: Peter Zijlstra (Intel) peterz@infradead.org Signed-off-by: Nathan Chancellor nathan@kernel.org Signed-off-by: Borislav Petkov (AMD) bp@alien8.de Link: https://lore.kernel.org/r/20230711091952.27944-2-petr.pavlu@suse.com Signed-off-by: Greg Kroah-Hartman gregkh@linuxfoundation.org --- arch/x86/kernel/vmlinux.lds.S | 8 ++++---- arch/x86/lib/retpoline.S | 8 ++++---- tools/objtool/check.c | 2 +- 3 files changed, 9 insertions(+), 9 deletions(-)
--- a/arch/x86/kernel/vmlinux.lds.S +++ b/arch/x86/kernel/vmlinux.lds.S @@ -134,7 +134,7 @@ SECTIONS KPROBES_TEXT ALIGN_ENTRY_TEXT_BEGIN #ifdef CONFIG_CPU_SRSO - *(.text.__x86.rethunk_untrain) + *(.text..__x86.rethunk_untrain) #endif
ENTRY_TEXT @@ -145,7 +145,7 @@ SECTIONS * definition. */ . = srso_alias_untrain_ret | (1 << 2) | (1 << 8) | (1 << 14) | (1 << 20); - *(.text.__x86.rethunk_safe) + *(.text..__x86.rethunk_safe) #endif ALIGN_ENTRY_TEXT_END SOFTIRQENTRY_TEXT @@ -154,8 +154,8 @@ SECTIONS
#ifdef CONFIG_RETPOLINE __indirect_thunk_start = .; - *(.text.__x86.indirect_thunk) - *(.text.__x86.return_thunk) + *(.text..__x86.indirect_thunk) + *(.text..__x86.return_thunk) __indirect_thunk_end = .; #endif } :text =0xcccc --- a/arch/x86/lib/retpoline.S +++ b/arch/x86/lib/retpoline.S @@ -11,7 +11,7 @@ #include <asm/frame.h> #include <asm/nops.h>
- .section .text.__x86.indirect_thunk + .section .text..__x86.indirect_thunk
.macro RETPOLINE reg ANNOTATE_INTRA_FUNCTION_CALL @@ -91,7 +91,7 @@ SYM_CODE_END(__x86_indirect_thunk_array) * As a result, srso_alias_safe_ret() becomes a safe return. */ #ifdef CONFIG_CPU_SRSO - .section .text.__x86.rethunk_untrain + .section .text..__x86.rethunk_untrain
SYM_START(srso_alias_untrain_ret, SYM_L_GLOBAL, SYM_A_NONE) UNWIND_HINT_FUNC @@ -102,7 +102,7 @@ SYM_START(srso_alias_untrain_ret, SYM_L_ SYM_FUNC_END(srso_alias_untrain_ret) __EXPORT_THUNK(srso_alias_untrain_ret)
- .section .text.__x86.rethunk_safe + .section .text..__x86.rethunk_safe #else /* dummy definition for alternatives */ SYM_START(srso_alias_untrain_ret, SYM_L_GLOBAL, SYM_A_NONE) @@ -120,7 +120,7 @@ SYM_START(srso_alias_safe_ret, SYM_L_GLO int3 SYM_FUNC_END(srso_alias_safe_ret)
- .section .text.__x86.return_thunk + .section .text..__x86.return_thunk
SYM_CODE_START(srso_alias_return_thunk) UNWIND_HINT_FUNC --- a/tools/objtool/check.c +++ b/tools/objtool/check.c @@ -379,7 +379,7 @@ static int decode_instructions(struct ob
if (!strcmp(sec->name, ".noinstr.text") || !strcmp(sec->name, ".entry.text") || - !strncmp(sec->name, ".text.__x86.", 12)) + !strncmp(sec->name, ".text..__x86.", 13)) sec->noinstr = true;
for (offset = 0; offset < sec->sh.sh_size; offset += insn->len) {
From: Peter Zijlstra peterz@infradead.org
commit dbf46008775516f7f25c95b7760041c286299783 upstream.
For stack-validation of a frame-pointer build, objtool validates that every CALL instruction is preceded by a frame-setup. The new SRSO return thunks violate this with their RSB stuffing trickery.
Extend the __fentry__ exception to also cover the embedded_insn case used for this. This cures:
vmlinux.o: warning: objtool: srso_untrain_ret+0xd: call without frame pointer save/setup
Fixes: 4ae68b26c3ab ("objtool/x86: Fix SRSO mess") Signed-off-by: Peter Zijlstra (Intel) peterz@infradead.org Signed-off-by: Borislav Petkov (AMD) bp@alien8.de Acked-by: Josh Poimboeuf jpoimboe@kernel.org Link: https://lore.kernel.org/r/20230816115921.GH980931@hirez.programming.kicks-as... Signed-off-by: Greg Kroah-Hartman gregkh@linuxfoundation.org --- tools/objtool/check.c | 17 +++++++++++------ 1 file changed, 11 insertions(+), 6 deletions(-)
--- a/tools/objtool/check.c +++ b/tools/objtool/check.c @@ -2450,12 +2450,17 @@ static int decode_sections(struct objtoo return 0; }
-static bool is_fentry_call(struct instruction *insn) +static bool is_special_call(struct instruction *insn) { - if (insn->type == INSN_CALL && - insn->call_dest && - insn->call_dest->fentry) - return true; + if (insn->type == INSN_CALL) { + struct symbol *dest = insn->call_dest; + + if (!dest) + return false; + + if (dest->fentry) + return true; + }
return false; } @@ -3448,7 +3453,7 @@ static int validate_branch(struct objtoo if (ret) return ret;
- if (opts.stackval && func && !is_fentry_call(insn) && + if (opts.stackval && func && !is_special_call(insn) && !has_valid_stack_frame(&state)) { WARN_FUNC("call without frame pointer save/setup", sec, insn->offset);
From: Borislav Petkov (AMD) bp@alien8.de
commit 6405b72e8d17bd1875a56ae52d23ec3cd51b9d66 upstream.
Specify how is SRSO mitigated when SMT is disabled. Also, correct the SMT check for that.
Fixes: e9fbc47b818b ("x86/srso: Disable the mitigation on unaffected configurations") Suggested-by: Josh Poimboeuf jpoimboe@kernel.org Signed-off-by: Borislav Petkov (AMD) bp@alien8.de Acked-by: Josh Poimboeuf jpoimboe@kernel.org Link: https://lore.kernel.org/r/20230814200813.p5czl47zssuej7nv@treble Signed-off-by: Greg Kroah-Hartman gregkh@linuxfoundation.org --- arch/x86/kernel/cpu/bugs.c | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-)
--- a/arch/x86/kernel/cpu/bugs.c +++ b/arch/x86/kernel/cpu/bugs.c @@ -2398,8 +2398,7 @@ static void __init srso_select_mitigatio * Zen1/2 with SMT off aren't vulnerable after the right * IBPB microcode has been applied. */ - if ((boot_cpu_data.x86 < 0x19) && - (!cpu_smt_possible() || (cpu_smt_control == CPU_SMT_DISABLED))) { + if (boot_cpu_data.x86 < 0x19 && !cpu_smt_possible()) { setup_force_cpu_cap(X86_FEATURE_SRSO_NO); return; } @@ -2689,7 +2688,7 @@ static ssize_t gds_show_state(char *buf) static ssize_t srso_show_state(char *buf) { if (boot_cpu_has(X86_FEATURE_SRSO_NO)) - return sysfs_emit(buf, "Not affected\n"); + return sysfs_emit(buf, "Mitigation: SMT disabled\n");
return sysfs_emit(buf, "%s%s\n", srso_strings[srso_mitigation],
On 8/24/23 07:14, Greg Kroah-Hartman wrote:
This is the start of the stable review cycle for the 6.1.48 release. There are 15 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
Responses should be made by Sat, 26 Aug 2023 14:14:28 +0000. Anything received after that time might be too late.
The whole patch series can be found in one patch at: https://www.kernel.org/pub/linux/kernel/v6.x/stable-review/patch-6.1.48-rc1.... or in the git tree and branch at: git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-6.1.y and the diffstat can be found below.
thanks,
greg k-h
On ARCH_BRCMSTB using 32-bit and 64-bit ARM kernels, build tested on BMIPS_GENERIC:
Tested-by: Florian Fainelli florian.fainelli@broadcom.com
I was not testing system wide suspend resume until recently and am seeing various issues with drivers that implement resume_noirq, but only on a specific platform, see below. I will see about bisecting that at some point.
[ 15.856930] Disabling non-boot CPUs ... [ 15.862349] CPU1 killed. [ 15.865684] Enabling non-boot CPUs ... [ 15.870067] CPU1 is up [ 15.872627] brcm-gisb-arb 47c400000.gisb-arb: PM: calling brcmstb_gisb_arb_resume_noirq+0x0/0x60 @ 1147, parent: rdb [ 15.883177] brcm-gisb-arb 47c400000.gisb-arb: PM: brcmstb_gisb_arb_resume_noirq+0x0/0x60 returned 0 after 2 usecs [ 15.893893] bcmgenet 47d580000.ethernet: PM: calling bcmgenet_resume_noirq+0x0/0xc0 @ 1147, parent: rdb [ 15.903611] bcmgenet 47d580000.ethernet: PM: bcmgenet_resume_noirq+0x0/0xc0 returned 0 after 303 usecs [ 36.902964] rcu: INFO: rcu_sched self-detected stall on CPU [ 36.908533] rcu: 0-....: (20991 ticks this GP) idle=0b1c/1/0x40000002 softirq=1785/1785 fqs=5251 [ 36.917402] (t=21008 jiffies g=1237 q=1 ncpus=2) [ 36.922104] CPU: 0 PID: 1147 Comm: rtcwake Not tainted 6.1.45-g02e3f13ba3f3 #2 [ 36.929321] Hardware name: Broadcom STB (Flattened Device Tree) [ 36.935234] PC is at _raw_spin_unlock_irqrestore+0x24/0x28 [ 36.940719] LR is at resume_irqs+0x9c/0x138 [ 36.944899] pc : [<c0d61f80>] lr : [<c028c9e0>] psr: 00030113 [ 36.951159] sp : d1165e28 ip : c391f200 fp : c2204d00 [ 36.956376] r10: c235e344 r9 : 40030113 r8 : c391f26c [ 36.961593] r7 : 00000000 r6 : c22489c0 r5 : 00000030 r4 : c391f200 [ 36.968113] r3 : 0000000e r2 : 00000500 r1 : 40030113 r0 : c391f26c [ 36.974634] Flags: nzcv IRQs on FIQs on Mode SVC_32 ISA ARM Segment user [ 36.981763] Control: 30c5383d Table: 036d12c0 DAC: fffffffd [ 36.987511] _raw_spin_unlock_irqrestore from resume_irqs+0x9c/0x138 [ 36.993865] resume_irqs from dpm_resume_noirq+0x14/0x1c [ 36.999178] dpm_resume_noirq from suspend_devices_and_enter+0x23c/0x890 [ 37.005884] suspend_devices_and_enter from pm_suspend+0x39c/0x414 [ 37.012063] pm_suspend from state_store+0x74/0xd4 [ 37.016852] state_store from kernfs_fop_write_iter+0x10c/0x1c4 [ 37.022779] kernfs_fop_write_iter from vfs_write+0x24c/0x354 [ 37.028532] vfs_write from ksys_write+0x60/0xd8 [ 37.033148] ksys_write from ret_fast_syscall+0x0/0x4c [ 37.038285] Exception stack(0xd1165fa8 to 0xd1165ff0) [ 37.043330] 5fa0: 00000004 004ab3e8 00000004 004ab3e8 00000004 00000000 [ 37.051502] 5fc0: 00000004 004ab3e8 004aa180 00000004 b6ef6b2c 0ee6b280 004aa180 0049703b [ 37.059673] 5fe0: 0000006c be89fb30 b6e21150 b6e7abbc
On 8/24/2023 2:31 PM, Florian Fainelli wrote:
On 8/24/23 07:14, Greg Kroah-Hartman wrote:
This is the start of the stable review cycle for the 6.1.48 release. There are 15 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
Responses should be made by Sat, 26 Aug 2023 14:14:28 +0000. Anything received after that time might be too late.
The whole patch series can be found in one patch at: https://www.kernel.org/pub/linux/kernel/v6.x/stable-review/patch-6.1.48-rc1.... or in the git tree and branch at: git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-6.1.y and the diffstat can be found below.
thanks,
greg k-h
On ARCH_BRCMSTB using 32-bit and 64-bit ARM kernels, build tested on BMIPS_GENERIC:
Tested-by: Florian Fainelli florian.fainelli@broadcom.com
I was not testing system wide suspend resume until recently and am seeing various issues with drivers that implement resume_noirq, but only on a specific platform, see below. I will see about bisecting that at some point.
This appears to be specific to drivers/rtc/rtc-brcmstb-waketimer.c nothing to be worried about for now.
Hello,
On Thu, 24 Aug 2023 16:14:56 +0200 Greg Kroah-Hartman gregkh@linuxfoundation.org wrote:
This is the start of the stable review cycle for the 6.1.48 release. There are 15 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
Responses should be made by Sat, 26 Aug 2023 14:14:28 +0000. Anything received after that time might be too late.
The whole patch series can be found in one patch at: https://www.kernel.org/pub/linux/kernel/v6.x/stable-review/patch-6.1.48-rc1.... or in the git tree and branch at: git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-6.1.y and the diffstat can be found below.
This rc kernel passes DAMON functionality test[1] on my test machine. Attaching the test results summary below. Please note that I retrieved the kernel from linux-stable-rc tree[2].
Tested-by: SeongJae Park sj@kernel.org
[1] https://github.com/awslabs/damon-tests/tree/next/corr [2] c079d0dd788a ("Linux 6.1.48-rc1")
Thanks, SJ
[...]
---
# .config:1408:warning: override: reassigning to symbol CGROUPS ok 15 selftests: damon-tests: build_nomemcg.sh # kselftest dir '/home/sjpark/damon-tests-cont/linux/tools/testing/selftests/damon-tests' is in dirty state. # the log is at '/home/sjpark/log'. [32m ok 1 selftests: damon: debugfs_attrs.sh ok 2 selftests: damon: debugfs_schemes.sh ok 3 selftests: damon: debugfs_target_ids.sh ok 4 selftests: damon: debugfs_empty_targets.sh ok 5 selftests: damon: debugfs_huge_count_read_write.sh ok 6 selftests: damon: debugfs_duplicate_context_creation.sh ok 7 selftests: damon: sysfs.sh ok 1 selftests: damon-tests: kunit.sh ok 2 selftests: damon-tests: huge_count_read_write.sh ok 3 selftests: damon-tests: buffer_overflow.sh ok 4 selftests: damon-tests: rm_contexts.sh ok 5 selftests: damon-tests: record_null_deref.sh ok 6 selftests: damon-tests: dbgfs_target_ids_read_before_terminate_race.sh ok 7 selftests: damon-tests: dbgfs_target_ids_pid_leak.sh ok 8 selftests: damon-tests: damo_tests.sh ok 9 selftests: damon-tests: masim-record.sh ok 10 selftests: damon-tests: build_i386.sh ok 11 selftests: damon-tests: build_m68k.sh ok 12 selftests: damon-tests: build_arm64.sh ok 13 selftests: damon-tests: build_i386_idle_flag.sh ok 14 selftests: damon-tests: build_i386_highpte.sh ok 15 selftests: damon-tests: build_nomemcg.sh [33m [92mPASS [39m _remote_run_corr.sh SUCCESS
On Thu, Aug 24, 2023 at 04:14:56PM +0200, Greg Kroah-Hartman wrote:
This is the start of the stable review cycle for the 6.1.48 release. There are 15 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
Responses should be made by Sat, 26 Aug 2023 14:14:28 +0000. Anything received after that time might be too late.
The whole patch series can be found in one patch at: https://www.kernel.org/pub/linux/kernel/v6.x/stable-review/patch-6.1.48-rc1.... or in the git tree and branch at: git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-6.1.y and the diffstat can be found below.
thanks,
greg k-h
For RCU, Tested-by: Joel Fernandes (Google) joel@joelfernandes.org
thanks,
- Joel
Pseudo-Shortlog of commits:
Greg Kroah-Hartman gregkh@linuxfoundation.org Linux 6.1.48-rc1
Borislav Petkov (AMD) bp@alien8.de x86/srso: Correct the mitigation status when SMT is disabled
Peter Zijlstra peterz@infradead.org objtool/x86: Fixup frame-pointer vs rethunk
Petr Pavlu petr.pavlu@suse.com x86/retpoline,kprobes: Fix position of thunk sections with CONFIG_LTO_CLANG
Borislav Petkov (AMD) bp@alien8.de x86/srso: Disable the mitigation on unaffected configurations
Borislav Petkov (AMD) bp@alien8.de x86/CPU/AMD: Fix the DIV(0) initial fix attempt
Sean Christopherson seanjc@google.com x86/retpoline: Don't clobber RFLAGS during srso_safe_ret()
Peter Zijlstra peterz@infradead.org x86/static_call: Fix __static_call_fixup()
Borislav Petkov (AMD) bp@alien8.de x86/srso: Explain the untraining sequences a bit more
Peter Zijlstra peterz@infradead.org x86/cpu: Cleanup the untrain mess
Peter Zijlstra peterz@infradead.org x86/cpu: Rename srso_(.*)_alias to srso_alias_\1
Peter Zijlstra peterz@infradead.org x86/cpu: Rename original retbleed methods
Peter Zijlstra peterz@infradead.org x86/cpu: Clean up SRSO return thunk mess
Peter Zijlstra peterz@infradead.org x86/alternative: Make custom return thunk unconditional
Peter Zijlstra peterz@infradead.org x86/cpu: Fix up srso_safe_ret() and __x86_return_thunk()
Peter Zijlstra peterz@infradead.org x86/cpu: Fix __x86_return_thunk symbol type
Diffstat:
Documentation/admin-guide/hw-vuln/srso.rst | 4 +- Makefile | 4 +- arch/x86/include/asm/entry-common.h | 1 + arch/x86/include/asm/nospec-branch.h | 28 +++--- arch/x86/kernel/cpu/amd.c | 1 + arch/x86/kernel/cpu/bugs.c | 28 +++++- arch/x86/kernel/static_call.c | 13 +++ arch/x86/kernel/traps.c | 2 - arch/x86/kernel/vmlinux.lds.S | 20 ++-- arch/x86/kvm/svm/svm.c | 2 + arch/x86/lib/retpoline.S | 141 ++++++++++++++++++++--------- tools/objtool/arch/x86/decode.c | 2 +- tools/objtool/check.c | 21 +++-- 13 files changed, 182 insertions(+), 85 deletions(-)
+ linux-nfs and more
On Thu, 24 Aug 2023 at 19:45, Greg Kroah-Hartman gregkh@linuxfoundation.org wrote:
This is the start of the stable review cycle for the 6.1.48 release. There are 15 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
Responses should be made by Sat, 26 Aug 2023 14:14:28 +0000. Anything received after that time might be too late.
The whole patch series can be found in one patch at: https://www.kernel.org/pub/linux/kernel/v6.x/stable-review/patch-6.1.48-rc1.... or in the git tree and branch at: git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-6.1.y and the diffstat can be found below.
thanks,
greg k-h
Following test regression found on stable-rc 6.1. Rpi4 is using NFS mount rootfs and running LTP syscalls testing. chown02 tests creating testfile2 on NFS mounted and validating the functionality and found that it was a failure.
This is already been reported by others on lore and fix patch merged into stable-rc linux-6.4.y [1] and [2].
Reported-by: Linux Kernel Functional Testing lkft@linaro.org
Test log: -------- chown02.c:46: TPASS: chown(testfile1, 0, 0) passed chown02.c:46: TPASS: chown(testfile2, 0, 0) passed chown02.c:58: TFAIL: testfile2: wrong mode permissions 0100700, expected 0102700
fchown02.c:57: TPASS: fchown(3, 0, 0) passed fchown02.c:57: TPASS: fchown(4, 0, 0) passed fchown02.c:67: TFAIL: testfile2: wrong mode permissions 0100700, expected 0102700
## Build * kernel: 6.1.48-rc1 * git: https://gitlab.com/Linaro/lkft/mirrors/stable/linux-stable-rc * git branch: linux-6.1.y * git commit: c079d0dd788ad4fe887ee6349fe89d23d72f7696 * git describe: v6.1.47-16-gc079d0dd788a * test details: https://qa-reports.linaro.org/lkft/linux-stable-rc-linux-6.1.y/build/v6.1.47...
## Test Regressions (compared to v6.1.46) * bcm2711-rpi-4-b, ltp-syscalls - chown02 - fchown02
* bcm2711-rpi-4-b-64k_page_size, ltp-syscalls - chown02 - fchown02
* bcm2711-rpi-4-b-clang, ltp-syscalls - chown02 - fchown02
Do we need the following patch into stable-rc linux-6.1.y ?
I see from mailing thread discussion, says that
the above commit is backported to LTS kernels -- 5.10.y,5.15.y and 6.1.y.
----
nfsd: use vfs setgid helper commit 2d8ae8c417db284f598dffb178cc01e7db0f1821 upstream.
We've aligned setgid behavior over multiple kernel releases. The details can be found in commit cf619f891971 ("Merge tag 'fs.ovl.setgid.v6.2' of git://git.kernel.org/pub/scm/linux/kernel/git/vfs/idmapping") and commit 426b4ca2d6a5 ("Merge tag 'fs.setgid.v6.0' of git://git.kernel.org/pub/scm/linux/kernel/git/brauner/linux"). Consistent setgid stripping behavior is now encapsulated in the setattr_should_drop_sgid() helper which is used by all filesystems that strip setgid bits outside of vfs proper. Usually ATTR_KILL_SGID is raised in e.g., chown_common() and is subject to the setattr_should_drop_sgid() check to determine whether the setgid bit can be retained. Since nfsd is raising ATTR_KILL_SGID unconditionally it will cause notify_change() to strip it even if the caller had the necessary privileges to retain it. Ensure that nfsd only raises ATR_KILL_SGID if the caller lacks the necessary privileges to retain the setgid bit.
Without this patch the setgid stripping tests in LTP will fail:
As you can see, the problem is S_ISGID (0002000) was dropped on a non-group-executable file while chown was invoked by super-user, while
[...]
fchown02.c:66: TFAIL: testfile2: wrong mode permissions 0100700, expected 0102700
[...]
chown02.c:57: TFAIL: testfile2: wrong mode permissions 0100700, expected 0102700
With this patch all tests pass.
Reported-by: Sherry Yang sherry.yang@oracle.com Signed-off-by: Christian Brauner brauner@kernel.org Reviewed-by: Jeff Layton jlayton@kernel.org Cc: stable@vger.kernel.org Signed-off-by: Chuck Lever chuck.lever@oracle.com Signed-off-by: Greg Kroah-Hartman gregkh@linuxfoundation.org
[1] https://lore.kernel.org/linux-nfs/20230502-agenda-regeln-04d2573bd0fd@braune... [2] https://lore.kernel.org/all/202210091600.dbe52cbf-yujie.liu@intel.com/ -- Linaro LKFT https://lkft.linaro.org
Hi,
On 25/08/23 12:35 pm, Naresh Kamboju wrote:
- linux-nfs and more
On Thu, 24 Aug 2023 at 19:45, Greg Kroah-Hartman gregkh@linuxfoundation.org wrote:
This is the start of the stable review cycle for the 6.1.48 release. There are 15 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
Responses should be made by Sat, 26 Aug 2023 14:14:28 +0000. Anything received after that time might be too late.
The whole patch series can be found in one patch at: https://www.kernel.org/pub/linux/kernel/v6.x/stable-review/patch-6.1.48-rc1.... or in the git tree and branch at: git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-6.1.y and the diffstat can be found below.
thanks,
greg k-h
Following test regression found on stable-rc 6.1. Rpi4 is using NFS mount rootfs and running LTP syscalls testing. chown02 tests creating testfile2 on NFS mounted and validating the functionality and found that it was a failure.
This is already been reported by others on lore and fix patch merged into stable-rc linux-6.4.y [1] and [2].
Reported-by: Linux Kernel Functional Testing lkft@linaro.org
Test log:
chown02.c:46: TPASS: chown(testfile1, 0, 0) passed chown02.c:46: TPASS: chown(testfile2, 0, 0) passed chown02.c:58: TFAIL: testfile2: wrong mode permissions 0100700, expected 0102700
fchown02.c:57: TPASS: fchown(3, 0, 0) passed fchown02.c:57: TPASS: fchown(4, 0, 0) passed fchown02.c:67: TFAIL: testfile2: wrong mode permissions 0100700, expected 0102700
Note: These both test cases are failing in 5.15.128 as well.
## Build
- kernel: 6.1.48-rc1
- git: https://gitlab.com/Linaro/lkft/mirrors/stable/linux-stable-rc
- git branch: linux-6.1.y
- git commit: c079d0dd788ad4fe887ee6349fe89d23d72f7696
- git describe: v6.1.47-16-gc079d0dd788a
- test details:
https://qa-reports.linaro.org/lkft/linux-stable-rc-linux-6.1.y/build/v6.1.47...
## Test Regressions (compared to v6.1.46)
bcm2711-rpi-4-b, ltp-syscalls
- chown02
- fchown02
bcm2711-rpi-4-b-64k_page_size, ltp-syscalls
- chown02
- fchown02
bcm2711-rpi-4-b-clang, ltp-syscalls
- chown02
- fchown02
Do we need the following patch into stable-rc linux-6.1.y ?
I see from mailing thread discussion, says that
the above commit is backported to LTS kernels -- 5.10.y,5.15.y and 6.1.y.
nfsd: use vfs setgid helper commit 2d8ae8c417db284f598dffb178cc01e7db0f1821 upstream.
We've aligned setgid behavior over multiple kernel releases. The details can be found in commit cf619f891971 ("Merge tag 'fs.ovl.setgid.v6.2' of git://git.kernel.org/pub/scm/linux/kernel/git/vfs/idmapping") and commit 426b4ca2d6a5 ("Merge tag 'fs.setgid.v6.0' of git://git.kernel.org/pub/scm/linux/kernel/git/brauner/linux"). Consistent setgid stripping behavior is now encapsulated in the setattr_should_drop_sgid() helper which is used by all filesystems that strip setgid bits outside of vfs proper. Usually ATTR_KILL_SGID is raised in e.g., chown_common() and is subject to the setattr_should_drop_sgid() check to determine whether the setgid bit can be retained. Since nfsd is raising ATTR_KILL_SGID unconditionally it will cause notify_change() to strip it even if the caller had the necessary privileges to retain it. Ensure that nfsd only raises ATR_KILL_SGID if the caller lacks the necessary privileges to retain the setgid bit.
Without this patch the setgid stripping tests in LTP will fail:
As you can see, the problem is S_ISGID (0002000) was dropped on a non-group-executable file while chown was invoked by super-user, while
[...]
fchown02.c:66: TFAIL: testfile2: wrong mode permissions 0100700, expected 0102700
[...]
chown02.c:57: TFAIL: testfile2: wrong mode permissions 0100700, expected 0102700
With this patch all tests pass.
Reported-by: Sherry Yang sherry.yang@oracle.com Signed-off-by: Christian Brauner brauner@kernel.org Reviewed-by: Jeff Layton jlayton@kernel.org Cc: stable@vger.kernel.org Signed-off-by: Chuck Lever chuck.lever@oracle.com Signed-off-by: Greg Kroah-Hartman gregkh@linuxfoundation.org
[1] https://lore.kernel.org/linux-nfs/20230502-agenda-regeln-04d2573bd0fd@braune... [2] https://lore.kernel.org/all/202210091600.dbe52cbf-yujie.liu@intel.com/ -- Linaro LKFT https://lkft.linaro.org
On Fri, Aug 25, 2023 at 12:35:46PM +0530, Naresh Kamboju wrote:
- linux-nfs and more
On Thu, 24 Aug 2023 at 19:45, Greg Kroah-Hartman gregkh@linuxfoundation.org wrote:
This is the start of the stable review cycle for the 6.1.48 release. There are 15 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
Responses should be made by Sat, 26 Aug 2023 14:14:28 +0000. Anything received after that time might be too late.
The whole patch series can be found in one patch at: https://www.kernel.org/pub/linux/kernel/v6.x/stable-review/patch-6.1.48-rc1.... or in the git tree and branch at: git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-6.1.y and the diffstat can be found below.
thanks,
greg k-h
Following test regression found on stable-rc 6.1. Rpi4 is using NFS mount rootfs and running LTP syscalls testing. chown02 tests creating testfile2 on NFS mounted and validating the functionality and found that it was a failure.
This is already been reported by others on lore and fix patch merged into stable-rc linux-6.4.y [1] and [2].
Reported-by: Linux Kernel Functional Testing lkft@linaro.org
Test log:
chown02.c:46: TPASS: chown(testfile1, 0, 0) passed chown02.c:46: TPASS: chown(testfile2, 0, 0) passed chown02.c:58: TFAIL: testfile2: wrong mode permissions 0100700, expected 0102700
fchown02.c:57: TPASS: fchown(3, 0, 0) passed fchown02.c:57: TPASS: fchown(4, 0, 0) passed fchown02.c:67: TFAIL: testfile2: wrong mode permissions 0100700, expected 0102700
## Build
- kernel: 6.1.48-rc1
- git: https://gitlab.com/Linaro/lkft/mirrors/stable/linux-stable-rc
- git branch: linux-6.1.y
- git commit: c079d0dd788ad4fe887ee6349fe89d23d72f7696
- git describe: v6.1.47-16-gc079d0dd788a
- test details:
https://qa-reports.linaro.org/lkft/linux-stable-rc-linux-6.1.y/build/v6.1.47...
## Test Regressions (compared to v6.1.46)
bcm2711-rpi-4-b, ltp-syscalls
- chown02
- fchown02
bcm2711-rpi-4-b-64k_page_size, ltp-syscalls
- chown02
- fchown02
bcm2711-rpi-4-b-clang, ltp-syscalls
- chown02
- fchown02
Do we need the following patch into stable-rc linux-6.1.y ?
I see from mailing thread discussion, says that
the above commit is backported to LTS kernels -- 5.10.y,5.15.y and 6.1.y.
s/above/below/?
All setgid related infrastructure and fixes have been backported to all LTSes. This one is needed for nfsd so yes, it should also be backported.
nfsd: use vfs setgid helper commit 2d8ae8c417db284f598dffb178cc01e7db0f1821 upstream.
We've aligned setgid behavior over multiple kernel releases. The details can be found in commit cf619f891971 ("Merge tag 'fs.ovl.setgid.v6.2' of git://git.kernel.org/pub/scm/linux/kernel/git/vfs/idmapping") and commit 426b4ca2d6a5 ("Merge tag 'fs.setgid.v6.0' of git://git.kernel.org/pub/scm/linux/kernel/git/brauner/linux"). Consistent setgid stripping behavior is now encapsulated in the setattr_should_drop_sgid() helper which is used by all filesystems that strip setgid bits outside of vfs proper. Usually ATTR_KILL_SGID is raised in e.g., chown_common() and is subject to the setattr_should_drop_sgid() check to determine whether the setgid bit can be retained. Since nfsd is raising ATTR_KILL_SGID unconditionally it will cause notify_change() to strip it even if the caller had the necessary privileges to retain it. Ensure that nfsd only raises ATR_KILL_SGID if the caller lacks the necessary privileges to retain the setgid bit.
Without this patch the setgid stripping tests in LTP will fail:
As you can see, the problem is S_ISGID (0002000) was dropped on a non-group-executable file while chown was invoked by super-user, while
[...]
fchown02.c:66: TFAIL: testfile2: wrong mode permissions 0100700, expected 0102700
[...]
chown02.c:57: TFAIL: testfile2: wrong mode permissions 0100700, expected 0102700
With this patch all tests pass.
Reported-by: Sherry Yang sherry.yang@oracle.com Signed-off-by: Christian Brauner brauner@kernel.org Reviewed-by: Jeff Layton jlayton@kernel.org Cc: stable@vger.kernel.org Signed-off-by: Chuck Lever chuck.lever@oracle.com Signed-off-by: Greg Kroah-Hartman gregkh@linuxfoundation.org
[1] https://lore.kernel.org/linux-nfs/20230502-agenda-regeln-04d2573bd0fd@braune... [2] https://lore.kernel.org/all/202210091600.dbe52cbf-yujie.liu@intel.com/ -- Linaro LKFT https://lkft.linaro.org
On Fri, Aug 25, 2023 at 12:35:46PM +0530, Naresh Kamboju wrote:
- linux-nfs and more
On Thu, 24 Aug 2023 at 19:45, Greg Kroah-Hartman gregkh@linuxfoundation.org wrote:
This is the start of the stable review cycle for the 6.1.48 release. There are 15 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
Responses should be made by Sat, 26 Aug 2023 14:14:28 +0000. Anything received after that time might be too late.
The whole patch series can be found in one patch at: https://www.kernel.org/pub/linux/kernel/v6.x/stable-review/patch-6.1.48-rc1.... or in the git tree and branch at: git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-6.1.y and the diffstat can be found below.
thanks,
greg k-h
Following test regression found on stable-rc 6.1. Rpi4 is using NFS mount rootfs and running LTP syscalls testing. chown02 tests creating testfile2 on NFS mounted and validating the functionality and found that it was a failure.
This is already been reported by others on lore and fix patch merged into stable-rc linux-6.4.y [1] and [2].
Reported-by: Linux Kernel Functional Testing lkft@linaro.org
Odd, it's not a regression in this -rc cycle, so it was missed in the previous ones somehow?
Test log:
chown02.c:46: TPASS: chown(testfile1, 0, 0) passed chown02.c:46: TPASS: chown(testfile2, 0, 0) passed chown02.c:58: TFAIL: testfile2: wrong mode permissions 0100700, expected 0102700
fchown02.c:57: TPASS: fchown(3, 0, 0) passed fchown02.c:57: TPASS: fchown(4, 0, 0) passed fchown02.c:67: TFAIL: testfile2: wrong mode permissions 0100700, expected 0102700
## Build
- kernel: 6.1.48-rc1
- git: https://gitlab.com/Linaro/lkft/mirrors/stable/linux-stable-rc
- git branch: linux-6.1.y
- git commit: c079d0dd788ad4fe887ee6349fe89d23d72f7696
- git describe: v6.1.47-16-gc079d0dd788a
- test details:
https://qa-reports.linaro.org/lkft/linux-stable-rc-linux-6.1.y/build/v6.1.47...
## Test Regressions (compared to v6.1.46)
bcm2711-rpi-4-b, ltp-syscalls
- chown02
- fchown02
bcm2711-rpi-4-b-64k_page_size, ltp-syscalls
- chown02
- fchown02
bcm2711-rpi-4-b-clang, ltp-syscalls
- chown02
- fchown02
Do we need the following patch into stable-rc linux-6.1.y ?
I see from mailing thread discussion, says that
the above commit is backported to LTS kernels -- 5.10.y,5.15.y and 6.1.y.
What "above commit"?
And what commit should be backported?
confused,
greg k-h
On Fri, 25 Aug 2023 at 13:57, Greg Kroah-Hartman gregkh@linuxfoundation.org wrote:
On Fri, Aug 25, 2023 at 12:35:46PM +0530, Naresh Kamboju wrote:
- linux-nfs and more
On Thu, 24 Aug 2023 at 19:45, Greg Kroah-Hartman gregkh@linuxfoundation.org wrote:
This is the start of the stable review cycle for the 6.1.48 release. There are 15 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
Responses should be made by Sat, 26 Aug 2023 14:14:28 +0000. Anything received after that time might be too late.
The whole patch series can be found in one patch at: https://www.kernel.org/pub/linux/kernel/v6.x/stable-review/patch-6.1.48-rc1.... or in the git tree and branch at: git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-6.1.y and the diffstat can be found below.
thanks,
greg k-h
Following test regression found on stable-rc 6.1. Rpi4 is using NFS mount rootfs and running LTP syscalls testing. chown02 tests creating testfile2 on NFS mounted and validating the functionality and found that it was a failure.
This is already been reported by others on lore and fix patch merged into stable-rc linux-6.4.y [1] and [2].
Reported-by: Linux Kernel Functional Testing lkft@linaro.org
Odd, it's not a regression in this -rc cycle, so it was missed in the previous ones somehow?
Test log:
chown02.c:46: TPASS: chown(testfile1, 0, 0) passed chown02.c:46: TPASS: chown(testfile2, 0, 0) passed chown02.c:58: TFAIL: testfile2: wrong mode permissions 0100700, expected 0102700
fchown02.c:57: TPASS: fchown(3, 0, 0) passed fchown02.c:57: TPASS: fchown(4, 0, 0) passed fchown02.c:67: TFAIL: testfile2: wrong mode permissions 0100700, expected 0102700
## Build
- kernel: 6.1.48-rc1
- git: https://gitlab.com/Linaro/lkft/mirrors/stable/linux-stable-rc
- git branch: linux-6.1.y
- git commit: c079d0dd788ad4fe887ee6349fe89d23d72f7696
- git describe: v6.1.47-16-gc079d0dd788a
- test details:
https://qa-reports.linaro.org/lkft/linux-stable-rc-linux-6.1.y/build/v6.1.47...
## Test Regressions (compared to v6.1.46)
bcm2711-rpi-4-b, ltp-syscalls
- chown02
- fchown02
bcm2711-rpi-4-b-64k_page_size, ltp-syscalls
- chown02
- fchown02
bcm2711-rpi-4-b-clang, ltp-syscalls
- chown02
- fchown02
Do we need the following patch into stable-rc linux-6.1.y ?
I see from mailing thread discussion, says that
the above commit is backported to LTS kernels -- 5.10.y,5.15.y and 6.1.y.
What "above commit"?
Sorry, s/above/below/ I copied that from another email thread as it is.
And what commit should be backported?
nfsd: use vfs setgid helper commit 2d8ae8c417db284f598dffb178cc01e7db0f1821 upstream.
Please refer this link, - https://lore.kernel.org/linux-nfs/20230502-agenda-regeln-04d2573bd0fd@braune...
confused,
greg k-h
Hi
On 25/08/23 2:18 pm, Naresh Kamboju wrote:
On Fri, 25 Aug 2023 at 13:57, Greg Kroah-Hartman gregkh@linuxfoundation.org wrote:
On Fri, Aug 25, 2023 at 12:35:46PM +0530, Naresh Kamboju wrote:
- linux-nfs and more
On Thu, 24 Aug 2023 at 19:45, Greg Kroah-Hartman gregkh@linuxfoundation.org wrote:
This is the start of the stable review cycle for the 6.1.48 release. There are 15 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
Responses should be made by Sat, 26 Aug 2023 14:14:28 +0000. Anything received after that time might be too late.
The whole patch series can be found in one patch at: https://www.kernel.org/pub/linux/kernel/v6.x/stable-review/patch-6.1.48-rc1.... or in the git tree and branch at: git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-6.1.y and the diffstat can be found below.
thanks,
greg k-h
Following test regression found on stable-rc 6.1. Rpi4 is using NFS mount rootfs and running LTP syscalls testing. chown02 tests creating testfile2 on NFS mounted and validating the functionality and found that it was a failure.
This is already been reported by others on lore and fix patch merged into stable-rc linux-6.4.y [1] and [2].
Reported-by: Linux Kernel Functional Testing lkft@linaro.org
Odd, it's not a regression in this -rc cycle, so it was missed in the previous ones somehow?
Test log:
chown02.c:46: TPASS: chown(testfile1, 0, 0) passed chown02.c:46: TPASS: chown(testfile2, 0, 0) passed chown02.c:58: TFAIL: testfile2: wrong mode permissions 0100700, expected 0102700
fchown02.c:57: TPASS: fchown(3, 0, 0) passed fchown02.c:57: TPASS: fchown(4, 0, 0) passed fchown02.c:67: TFAIL: testfile2: wrong mode permissions 0100700, expected 0102700
## Build
- kernel: 6.1.48-rc1
- git: https://gitlab.com/Linaro/lkft/mirrors/stable/linux-stable-rc
- git branch: linux-6.1.y
- git commit: c079d0dd788ad4fe887ee6349fe89d23d72f7696
- git describe: v6.1.47-16-gc079d0dd788a
- test details:
https://qa-reports.linaro.org/lkft/linux-stable-rc-linux-6.1.y/build/v6.1.47...
## Test Regressions (compared to v6.1.46)
bcm2711-rpi-4-b, ltp-syscalls
- chown02
- fchown02
bcm2711-rpi-4-b-64k_page_size, ltp-syscalls
- chown02
- fchown02
bcm2711-rpi-4-b-clang, ltp-syscalls
- chown02
- fchown02
Do we need the following patch into stable-rc linux-6.1.y ?
I see from mailing thread discussion, says that
the above commit is backported to LTS kernels -- 5.10.y,5.15.y and 6.1.y.
What "above commit"?
Sorry, s/above/below/ I copied that from another email thread as it is.
And what commit should be backported?
nfsd: use vfs setgid helper commit 2d8ae8c417db284f598dffb178cc01e7db0f1821 upstream.
I have tried backporting this on 6.1.y and 5.15.y.
Here are the backports. (note: I would like to have them reviewed)
6.1.y: https://lore.kernel.org/all/20230825161603.371792-1-harshit.m.mogalapalli@or...
5.15.y: https://lore.kernel.org/all/20230825161901.371818-1-harshit.m.mogalapalli@or...
Thanks, Harshit
Please refer this link,
confused,
greg k-h
On Fri, 25 Aug 2023 at 13:57, Greg Kroah-Hartman gregkh@linuxfoundation.org wrote:
On Fri, Aug 25, 2023 at 12:35:46PM +0530, Naresh Kamboju wrote:
- linux-nfs and more
On Thu, 24 Aug 2023 at 19:45, Greg Kroah-Hartman gregkh@linuxfoundation.org wrote:
This is the start of the stable review cycle for the 6.1.48 release. There are 15 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
Responses should be made by Sat, 26 Aug 2023 14:14:28 +0000. Anything received after that time might be too late.
The whole patch series can be found in one patch at: https://www.kernel.org/pub/linux/kernel/v6.x/stable-review/patch-6.1.48-rc1.... or in the git tree and branch at: git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-6.1.y and the diffstat can be found below.
thanks,
greg k-h
Following test regression found on stable-rc 6.1. Rpi4 is using NFS mount rootfs and running LTP syscalls testing. chown02 tests creating testfile2 on NFS mounted and validating the functionality and found that it was a failure.
This is already been reported by others on lore and fix patch merged into stable-rc linux-6.4.y [1] and [2].
Reported-by: Linux Kernel Functional Testing lkft@linaro.org
Odd, it's not a regression in this -rc cycle, so it was missed in the previous ones somehow?
I have re-tested with newers and older versions of the kernel and here I confirm that this is not a regression from this round of stable rc review.
We have made a couple of changes to our infrastructure and are investigating the root cause of these two test cases failures.
- Naresh
Hi Greg,
On Thu, Aug 24, 2023 at 04:14:56PM +0200, Greg Kroah-Hartman wrote:
This is the start of the stable review cycle for the 6.1.48 release. There are 15 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
Responses should be made by Sat, 26 Aug 2023 14:14:28 +0000. Anything received after that time might be too late.
Build test (gcc version 12.3.1 20230625): mips: 52 configs -> no failure arm: 100 configs -> no failure arm64: 3 configs -> no failure x86_64: 4 configs -> no failure alpha allmodconfig -> no failure csky allmodconfig -> no failure powerpc allmodconfig -> no failure riscv allmodconfig -> no failure s390 allmodconfig -> no failure xtensa allmodconfig -> no failure
Boot test: x86_64: Booted on my test laptop. Warning on boot. x86_64: Booted on qemu. Warning on boot. [1] arm64: Booted on rpi4b (4GB model). No regression. [2] mips: Booted on ci20 board. No regression. [3]
[1]. https://openqa.qa.codethink.co.uk/tests/4787 [2]. https://openqa.qa.codethink.co.uk/tests/4796 [3]. https://openqa.qa.codethink.co.uk/tests/4795
Tested-by: Sudip Mukherjee sudip.mukherjee@codethink.co.uk
[ 0.154501] ------------[ cut here ]------------ [ 0.154505] missing return thunk: __alt_instructions_end+0x21b2/0x21d0-srso_untrain_ret+0x0/0x2: e9 17 81 f8 fe [ 0.154517] WARNING: CPU: 0 PID: 0 at arch/x86/kernel/alternative.c:572 apply_returns+0x1cb/0x200 [ 0.154524] Modules linked in: [ 0.154526] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 6.1.48-rc1-c079d0dd788a+ #1 [ 0.154529] Hardware name: LENOVO 4287CTO/4287CTO, BIOS 8DET68WW (1.38 ) 04/11/2013 [ 0.154531] RIP: 0010:apply_returns+0x1cb/0x200 [ 0.154534] Code: 5b 01 00 0f 85 0b ff ff ff 49 89 e8 b9 05 00 00 00 4c 89 f2 48 89 ee 48 c7 c7 38 16 4f b8 c6 05 f5 d1 5b 01 01 e8 85 8e 05 00 <0f> 0b e9 e3 fe ff ff c7 84 24 81 00 00 00 cc cc cc cc 42 c7 44 38 [ 0.154536] RSP: 0000:ffffffffb8803e30 EFLAGS: 00010282 [ 0.154539] RAX: 0000000000000000 RBX: ffffffffb906d7b4 RCX: 0000000000000000 [ 0.154541] RDX: 0000000000000003 RSI: 0000000000004ffb RDI: 00000000ffffffff [ 0.154542] RBP: ffffffffb9079962 R08: 0000000000000000 R09: 00000000ffffefff [ 0.154544] R10: ffffffffb8803cc0 R11: ffffffffb88cc1e8 R12: ffffffffb906d7d4 [ 0.154545] R13: cccccccccccccccc R14: ffffffffb8001a7e R15: 0000000000000004 [ 0.154547] FS: 0000000000000000(0000) GS:ffff936dd6200000(0000) knlGS:0000000000000000 [ 0.154549] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 0.154551] CR2: ffff936dde5ff000 CR3: 000000013b40a001 CR4: 00000000000606f0 [ 0.154553] Call Trace: [ 0.154556] <TASK> [ 0.154559] ? __warn+0x79/0xc0 [ 0.154565] ? apply_returns+0x1cb/0x200 [ 0.154567] ? report_bug+0xee/0x170 [ 0.154572] ? prb_read_valid+0x17/0x20 [ 0.154578] ? handle_bug+0x42/0x70 [ 0.154581] ? exc_invalid_op+0x14/0x70 [ 0.154583] ? asm_exc_invalid_op+0x16/0x20 [ 0.154586] ? retbleed_return_thunk+0x7e/0x7e [ 0.154591] ? apply_returns+0x1cb/0x200 [ 0.154594] ? apply_retpolines+0x1f5/0x2c0 [ 0.154598] alternative_instructions+0x4d/0xfc [ 0.154604] arch_cpu_finalize_init+0x28/0x47 [ 0.154607] start_kernel+0x66c/0x70e [ 0.154612] secondary_startup_64_no_verify+0xce/0xdb [ 0.154618] </TASK> [ 0.154619] ---[ end trace 0000000000000000 ]---
Hi On Fri, Aug 25, 2023 at 10:26:59AM +0100, Sudip Mukherjee (Codethink) wrote:
Hi Greg,
On Thu, Aug 24, 2023 at 04:14:56PM +0200, Greg Kroah-Hartman wrote:
This is the start of the stable review cycle for the 6.1.48 release. There are 15 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
Responses should be made by Sat, 26 Aug 2023 14:14:28 +0000. Anything received after that time might be too late.
Build test (gcc version 12.3.1 20230625): mips: 52 configs -> no failure arm: 100 configs -> no failure arm64: 3 configs -> no failure x86_64: 4 configs -> no failure alpha allmodconfig -> no failure csky allmodconfig -> no failure powerpc allmodconfig -> no failure riscv allmodconfig -> no failure s390 allmodconfig -> no failure xtensa allmodconfig -> no failure
Boot test: x86_64: Booted on my test laptop. Warning on boot. x86_64: Booted on qemu. Warning on boot. [1] arm64: Booted on rpi4b (4GB model). No regression. [2] mips: Booted on ci20 board. No regression. [3]
[1]. https://openqa.qa.codethink.co.uk/tests/4787 [2]. https://openqa.qa.codethink.co.uk/tests/4796 [3]. https://openqa.qa.codethink.co.uk/tests/4795
Tested-by: Sudip Mukherjee sudip.mukherjee@codethink.co.uk
[ 0.154501] ------------[ cut here ]------------ [ 0.154505] missing return thunk: __alt_instructions_end+0x21b2/0x21d0-srso_untrain_ret+0x0/0x2: e9 17 81 f8 fe [ 0.154517] WARNING: CPU: 0 PID: 0 at arch/x86/kernel/alternative.c:572 apply_returns+0x1cb/0x200 [ 0.154524] Modules linked in: [ 0.154526] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 6.1.48-rc1-c079d0dd788a+ #1 [ 0.154529] Hardware name: LENOVO 4287CTO/4287CTO, BIOS 8DET68WW (1.38 ) 04/11/2013 [ 0.154531] RIP: 0010:apply_returns+0x1cb/0x200 [ 0.154534] Code: 5b 01 00 0f 85 0b ff ff ff 49 89 e8 b9 05 00 00 00 4c 89 f2 48 89 ee 48 c7 c7 38 16 4f b8 c6 05 f5 d1 5b 01 01 e8 85 8e 05 00 <0f> 0b e9 e3 fe ff ff c7 84 24 81 00 00 00 cc cc cc cc 42 c7 44 38 [ 0.154536] RSP: 0000:ffffffffb8803e30 EFLAGS: 00010282 [ 0.154539] RAX: 0000000000000000 RBX: ffffffffb906d7b4 RCX: 0000000000000000 [ 0.154541] RDX: 0000000000000003 RSI: 0000000000004ffb RDI: 00000000ffffffff [ 0.154542] RBP: ffffffffb9079962 R08: 0000000000000000 R09: 00000000ffffefff [ 0.154544] R10: ffffffffb8803cc0 R11: ffffffffb88cc1e8 R12: ffffffffb906d7d4 [ 0.154545] R13: cccccccccccccccc R14: ffffffffb8001a7e R15: 0000000000000004 [ 0.154547] FS: 0000000000000000(0000) GS:ffff936dd6200000(0000) knlGS:0000000000000000 [ 0.154549] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 0.154551] CR2: ffff936dde5ff000 CR3: 000000013b40a001 CR4: 00000000000606f0 [ 0.154553] Call Trace: [ 0.154556] <TASK> [ 0.154559] ? __warn+0x79/0xc0 [ 0.154565] ? apply_returns+0x1cb/0x200 [ 0.154567] ? report_bug+0xee/0x170 [ 0.154572] ? prb_read_valid+0x17/0x20 [ 0.154578] ? handle_bug+0x42/0x70 [ 0.154581] ? exc_invalid_op+0x14/0x70 [ 0.154583] ? asm_exc_invalid_op+0x16/0x20 [ 0.154586] ? retbleed_return_thunk+0x7e/0x7e [ 0.154591] ? apply_returns+0x1cb/0x200 [ 0.154594] ? apply_retpolines+0x1f5/0x2c0 [ 0.154598] alternative_instructions+0x4d/0xfc [ 0.154604] arch_cpu_finalize_init+0x28/0x47 [ 0.154607] start_kernel+0x66c/0x70e [ 0.154612] secondary_startup_64_no_verify+0xce/0xdb [ 0.154618] </TASK> [ 0.154619] ---[ end trace 0000000000000000 ]---
Seeing this as well, but see some context in the thread in the previous cycle (where then those patches were not included);
https://lore.kernel.org/stable/2023082212-pregnant-lizard-80e0@gregkh/
Apart for the above regression, no other regressions spotted.
Tested-by: Salvatore Bonaccorso carnil@debian.org
Regards, Salvatore
On Thu, 24 Aug 2023 at 19:45, Greg Kroah-Hartman gregkh@linuxfoundation.org wrote:
This is the start of the stable review cycle for the 6.1.48 release. There are 15 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
Responses should be made by Sat, 26 Aug 2023 14:14:28 +0000. Anything received after that time might be too late.
The whole patch series can be found in one patch at: https://www.kernel.org/pub/linux/kernel/v6.x/stable-review/patch-6.1.48-rc1.... or in the git tree and branch at: git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-6.1.y and the diffstat can be found below.
thanks,
greg k-h
Results from Linaro’s test farm. No regressions on arm64, arm, x86_64, and i386.
Tested-by: Linux Kernel Functional Testing lkft@linaro.org
NOTE: 1) LTP syscalls chown02 and fchown02 test failures on NFS mounted filesystem on arm64 Rpi4 will be investigated further.
2) While booting x86_64 we have been noticing this kernel warning but the system is stable and running other test cases.
kernel warning on x86_64, [ 0.809960] missing return thunk: __alt_instructions_end+0x2743/0x2770-srso_untrain_ret+0x0/0x2: e9 7e fd 09 ff [ 0.811301] WARNING: CPU: 0 PID: 0 at arch/x86/kernel/alternative.c:572 apply_returns+0x1d7/0x200 [ 0.812587] Modules linked in: [ 0.813651] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 6.1.48-rc1 #1 [ 0.814120] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.2-debian-1.16.2-1 04/01/2014 [ 0.814120] RIP: 0010:apply_returns+0x1d7/0x200
## Build * kernel: 6.1.48-rc1 * git: https://gitlab.com/Linaro/lkft/mirrors/stable/linux-stable-rc * git branch: linux-6.1.y * git commit: c079d0dd788ad4fe887ee6349fe89d23d72f7696 * git describe: v6.1.47-16-gc079d0dd788a * test details: https://qa-reports.linaro.org/lkft/linux-stable-rc-linux-6.1.y/build/v6.1.47...
## Test Regressions (compared to v6.1.46)
## Metric Regressions (compared to v6.1.46)
## Test Fixes (compared to v6.1.46)
## Metric Fixes (compared to v6.1.46)
## Test result summary total: 165563, pass: 138512, fail: 5138, skip: 21721, xfail: 192
## Build Summary * arc: 5 total, 5 passed, 0 failed * arm: 151 total, 149 passed, 2 failed * arm64: 56 total, 53 passed, 3 failed * i386: 41 total, 39 passed, 2 failed * mips: 30 total, 28 passed, 2 failed * parisc: 4 total, 4 passed, 0 failed * powerpc: 38 total, 36 passed, 2 failed * riscv: 16 total, 13 passed, 3 failed * s390: 16 total, 14 passed, 2 failed * sh: 14 total, 12 passed, 2 failed * sparc: 8 total, 8 passed, 0 failed * x86_64: 46 total, 44 passed, 2 failed
## Test suites summary * boot * kselftest-android * kselftest-arm64 * kselftest-breakpoints * kselftest-capabilities * kselftest-cgroup * kselftest-clone3 * kselftest-core * kselftest-cpu-hotplug * kselftest-cpufreq * kselftest-drivers-dma-buf * kselftest-efivarfs * kselftest-exec * kselftest-filesystems * kselftest-filesystems-binderfs * kselftest-filesystems-epoll * kselftest-firmware * kselftest-fpu * kselftest-ftrace * kselftest-futex * kselftest-gpio * kselftest-intel_pstate * kselftest-ipc * kselftest-ir * kselftest-kcmp * kselftest-kexec * kselftest-kvm * kselftest-lib * kselftest-membarrier * kselftest-memfd * kselftest-memory-hotplug * kselftest-mincore * kselftest-mount * kselftest-mqueue * kselftest-net * kselftest-net-forwarding * kselftest-net-mptcp * kselftest-netfilter * kselftest-nsfs * kselftest-openat2 * kselftest-pid_namespace * kselftest-pidfd * kselftest-proc * kselftest-pstore * kselftest-ptrace * kselftest-rseq * kselftest-rtc * kselftest-seccomp * kselftest-sigaltstack * kselftest-size * kselftest-splice * kselftest-static_keys * kselftest-sync * kselftest-sysctl * kselftest-tc-testing * kselftest-timens * kselftest-timers * kselftest-tmpfs * kselftest-tpm2 * kselftest-user * kselftest-user_events * kselftest-vDSO * kselftest-vm * kselftest-watchdog * kselftest-x86 * kselftest-zram * kunit * kvm-unit-tests * libgpiod * log-parser-boot * log-parser-test * ltp-cap_bounds * ltp-commands * ltp-containers * ltp-controllers * ltp-cpuhotplug * ltp-crypto * ltp-cve * ltp-dio * ltp-fcntl-locktests * ltp-filecaps * ltp-fs * ltp-fs_bind * ltp-fs_perms_simple * ltp-fsx * ltp-hugetlb * ltp-io * ltp-ipc * ltp-math * ltp-mm * ltp-nptl * ltp-pty * ltp-sched * ltp-securebits * ltp-smoke * ltp-syscalls * ltp-tracing * network-basic-tests * perf * rcutorture * v4l2-compliance
-- Linaro LKFT https://lkft.linaro.org
On Thu, 24 Aug 2023 16:14:56 +0200, Greg Kroah-Hartman wrote:
This is the start of the stable review cycle for the 6.1.48 release. There are 15 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
Responses should be made by Sat, 26 Aug 2023 14:14:28 +0000. Anything received after that time might be too late.
The whole patch series can be found in one patch at: https://www.kernel.org/pub/linux/kernel/v6.x/stable-review/patch-6.1.48-rc1.... or in the git tree and branch at: git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-6.1.y and the diffstat can be found below.
thanks,
greg k-h
All tests passing for Tegra ...
Test results for stable-v6.1: 11 builds: 11 pass, 0 fail 28 boots: 28 pass, 0 fail 125 tests: 125 pass, 0 fail
Linux version: 6.1.48-rc1-gc079d0dd788a Boards tested: tegra124-jetson-tk1, tegra186-p2771-0000, tegra194-p2972-0000, tegra194-p3509-0000+p3668-0000, tegra20-ventana, tegra210-p2371-2180, tegra210-p3450-0000, tegra30-cardhu-a04
Tested-by: Jon Hunter jonathanh@nvidia.com
Jon
On Thu, Aug 24, 2023 at 04:14:56PM +0200, Greg Kroah-Hartman wrote:
This is the start of the stable review cycle for the 6.1.48 release. There are 15 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
SRSO mitigations are probably not in the slightest bit relevant for me, but I didn't get a chance to retest the previous stable release after the build got unbricked for RISC-V, so: Tested-by: Conor Dooley conor.dooley@microchip.com
Fix for the build issue I saw should be on it's way to Linus today, so I guess the original fix you were backporting & its fix should end up back in your queue soonTM.
Thanks, Conor.
Responses should be made by Sat, 26 Aug 2023 14:14:28 +0000. Anything received after that time might be too late.
The whole patch series can be found in one patch at: https://www.kernel.org/pub/linux/kernel/v6.x/stable-review/patch-6.1.48-rc1.... or in the git tree and branch at: git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-6.1.y and the diffstat can be found below.
thanks,
greg k-h
Pseudo-Shortlog of commits:
Greg Kroah-Hartman gregkh@linuxfoundation.org Linux 6.1.48-rc1
Borislav Petkov (AMD) bp@alien8.de x86/srso: Correct the mitigation status when SMT is disabled
Peter Zijlstra peterz@infradead.org objtool/x86: Fixup frame-pointer vs rethunk
Petr Pavlu petr.pavlu@suse.com x86/retpoline,kprobes: Fix position of thunk sections with CONFIG_LTO_CLANG
Borislav Petkov (AMD) bp@alien8.de x86/srso: Disable the mitigation on unaffected configurations
Borislav Petkov (AMD) bp@alien8.de x86/CPU/AMD: Fix the DIV(0) initial fix attempt
Sean Christopherson seanjc@google.com x86/retpoline: Don't clobber RFLAGS during srso_safe_ret()
Peter Zijlstra peterz@infradead.org x86/static_call: Fix __static_call_fixup()
Borislav Petkov (AMD) bp@alien8.de x86/srso: Explain the untraining sequences a bit more
Peter Zijlstra peterz@infradead.org x86/cpu: Cleanup the untrain mess
Peter Zijlstra peterz@infradead.org x86/cpu: Rename srso_(.*)_alias to srso_alias_\1
Peter Zijlstra peterz@infradead.org x86/cpu: Rename original retbleed methods
Peter Zijlstra peterz@infradead.org x86/cpu: Clean up SRSO return thunk mess
Peter Zijlstra peterz@infradead.org x86/alternative: Make custom return thunk unconditional
Peter Zijlstra peterz@infradead.org x86/cpu: Fix up srso_safe_ret() and __x86_return_thunk()
Peter Zijlstra peterz@infradead.org x86/cpu: Fix __x86_return_thunk symbol type
Diffstat:
Documentation/admin-guide/hw-vuln/srso.rst | 4 +- Makefile | 4 +- arch/x86/include/asm/entry-common.h | 1 + arch/x86/include/asm/nospec-branch.h | 28 +++--- arch/x86/kernel/cpu/amd.c | 1 + arch/x86/kernel/cpu/bugs.c | 28 +++++- arch/x86/kernel/static_call.c | 13 +++ arch/x86/kernel/traps.c | 2 - arch/x86/kernel/vmlinux.lds.S | 20 ++-- arch/x86/kvm/svm/svm.c | 2 + arch/x86/lib/retpoline.S | 141 ++++++++++++++++++++--------- tools/objtool/arch/x86/decode.c | 2 +- tools/objtool/check.c | 21 +++-- 13 files changed, 182 insertions(+), 85 deletions(-)
Hi Greg
On Thu, Aug 24, 2023 at 11:16 PM Greg Kroah-Hartman gregkh@linuxfoundation.org wrote:
This is the start of the stable review cycle for the 6.1.48 release. There are 15 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
Responses should be made by Sat, 26 Aug 2023 14:14:28 +0000. Anything received after that time might be too late.
The whole patch series can be found in one patch at: https://www.kernel.org/pub/linux/kernel/v6.x/stable-review/patch-6.1.48-rc1.... or in the git tree and branch at: git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-6.1.y and the diffstat can be found below.
thanks,
greg k-h
6.1.48-rc1 tested.
Build successfully completed. Boot successfully completed. No dmesg regressions. Video output normal. Sound output normal.
Lenovo ThinkPad X1 Carbon Gen10(Intel i7-1260P(x86_64) arch linux)
Thanks
Tested-by: Takeshi Ogasawara takeshi.ogasawara@futuring-girl.com
On Thu, Aug 24, 2023 at 04:14:56PM +0200, Greg Kroah-Hartman wrote:
This is the start of the stable review cycle for the 6.1.48 release. There are 15 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
Responses should be made by Sat, 26 Aug 2023 14:14:28 +0000. Anything received after that time might be too late.
Build results: total: 157 pass: 156 fail: 1 Failed builds: m68k:sun3_defconfig Qemu test results: total: 521 pass: 519 fail: 2 Failed tests: arm:fuji-bmc:aspeed_g5_defconfig:notests:mem1G:mtd128,0,8,1:net,nic:aspeed-bmc-facebook-fuji:f2fs arm:bletchley-bmc,fmc-model=mt25qu02g,spi-model=mt25qu02g:aspeed_g5_defconfig:notests:mem1G:mtd256:net,nic:aspeed-bmc-facebook-bletchley:f2fs
The usual f2fs crashes, and m68k:sun3_defconfig still fails to build with "Inconsistent kallsyms data".
Guenter
On 8/24/23 08:14, Greg Kroah-Hartman wrote:
This is the start of the stable review cycle for the 6.1.48 release. There are 15 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
Responses should be made by Sat, 26 Aug 2023 14:14:28 +0000. Anything received after that time might be too late.
The whole patch series can be found in one patch at: https://www.kernel.org/pub/linux/kernel/v6.x/stable-review/patch-6.1.48-rc1.... or in the git tree and branch at: git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-6.1.y and the diffstat can be found below.
thanks,
greg k-h
Compiled and booted on my test system. No dmesg regressions.
Tested-by: Shuah Khan skhan@linuxfoundation.org
thanks, -- Shuah
On Thu, Aug 24, 2023 at 04:14:56PM +0200, Greg Kroah-Hartman wrote:
This is the start of the stable review cycle for the 6.1.48 release. There are 15 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
Successfully compiled and installed bindeb-pkgs on my computer (Acer Aspire E15, Intel Core i3 Haswell). No noticeable regressions.
Tested-by: Bagas Sanjaya bagasdotme@gmail.com
linux-stable-mirror@lists.linaro.org