On Fri, Nov 24, 2023 at 01:34:35PM +0530, Caleb Jorden wrote: > I have noticed on my zen3 and zen4 machines (Ryzen 9 5950x & Ryzen 9 > 7950x) that the kernel boot log regarding SRSO is suddenly incorrect > with the 6.6.2 kernel. > > I have observed this on a completely mainline/stable kernel that I > compile regularly for my machines. With the 6.6.1 and 6.7-rc2 > kernels, I see correct boot messages like this: > > [ 0.161327] Spectre V1 : Mitigation: usercopy/swapgs barriers and > __user pointer sanitization > [ 0.161329] Spectre V2 : Mitigation: Retpolines > [ 0.161330] Spectre V2 : Spectre v2 / SpectreRSB mitigation: > Filling RSB on context switch > [ 0.161331] Spectre V2 : Spectre v2 / SpectreRSB : Filling RSB on VMEXIT > [ 0.161332] Spectre V2 : Enabling Restricted Speculation for firmware calls > [ 0.161333] Spectre V2 : mitigation: Enabling conditional Indirect > Branch Prediction Barrier > [ 0.161335] Spectre V2 : User space: Mitigation: STIBP always-on protection > [ 0.161336] Speculative Store Bypass: Mitigation: Speculative Store > Bypass disabled via prctl > [ 0.161338] Speculative Return Stack Overflow: Mitigation: safe RET > > However, with the 6.6.2 kernel, I see this: > > [ 0.164266] Spectre V1 : Mitigation: usercopy/swapgs barriers and > __user pointer sanitization > [ 0.164268] Spectre V2 : Mitigation: Retpolines > [ 0.164269] Spectre V2 : Spectre v2 / SpectreRSB mitigation: > Filling RSB on context switch > [ 0.164270] Spectre V2 : Spectre v2 / SpectreRSB : Filling RSB on VMEXIT > [ 0.164272] Spectre V2 : Enabling Restricted Speculation for firmware calls > [ 0.164273] Spectre V2 : mitigation: Enabling conditional Indirect > Branch Prediction Barrier > [ 0.164275] Spectre V2 : User space: Mitigation: STIBP always-on protection > [ 0.164276] Speculative Store Bypass: Mitigation: Speculative Store > Bypass disabled via prctl > [ 0.164278] Speculative Return Stack Overflow: IBPB-extending > microcode not applied! > [ 0.164279] Speculative Return Stack Overflow: WARNING: See > https://kernel.org/doc/html/latest/admin-guide/hw-vuln/srso.html for > mitigation options. > [ 0.164280] Speculative Return Stack Overflow: Mitigation: Safe RET > > Notice that in both cases the final SRSO message indicates (correctly) > that my system is protected with Safe RET (because my BIOS has the > updated microcode for SRSO). However, in the 6.6.2 kernel I also get > the microcode warning. > > I tracked this down to, what I believe is, the following commit from > the mainline kernel not being included in the 6.6.2 patch set: > 351236947a45a512c517153bbe109fe868d05e6d x86/srso: Move retbleed IBPB > check into existing 'has_microcode' code block > > When I cherry-pick this commit to the 6.6.2 release, the log messages > are correct. Note that this patch does not obviously indicate there > is a functional change introduced by applying it. However (at least > in the case of Zen3 and Zen4) when the updated microcode has been > applied, the flow is different (specifically the situation that falls > into the else statement that produces the pr-warn calls to indicate > that the microcode fix needs applied). I believe this might be > because RETBLEED does not apply to Zen3 and Zen4. Unfortunately I > don't have a Zen1 or Zen2 system readily available on which to test > this theory. > > While this should only be a cosmetic change, I believe that there is > value in having the correct messages in the kernel logs for SRSO in > this LTS release. > > Please feel free to correct my analysis above if it is incorrect. No, you're correct, 6.6-stable needs that patch. stable folks, can you pls pick up: 351236947a45 ("x86/srso: Move retbleed IBPB check into existing 'has_microcode' code block") ? See above why. Thx. -- Regards/Gruss, Boris. https://people.kernel.org/tglx/notes-about-netiquette
