On Fri, Nov 24, 2023 at 02:40:25PM +0100, Borislav Petkov wrote: > 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. Now queued up, thanks! greg k-h
