Re: [Regression] Linux-6.6.2: SRSO kernel log messages incorrect

[Greg KH <gregkh@linuxfoundation.org>]

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