* [Regression] Linux-6.6.2: SRSO kernel log messages incorrect
@ 2023-11-24 8:04 Caleb Jorden
2023-11-24 13:40 ` Borislav Petkov
0 siblings, 1 reply; 3+ messages in thread
From: Caleb Jorden @ 2023-11-24 8:04 UTC (permalink / raw)
To: Josh Poimboeuf, Borislav Petkov; +Cc: stable, Thomas Gleixner
Hello,
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.
Warm Regards,
Caleb Jorden
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: [Regression] Linux-6.6.2: SRSO kernel log messages incorrect
2023-11-24 8:04 [Regression] Linux-6.6.2: SRSO kernel log messages incorrect Caleb Jorden
@ 2023-11-24 13:40 ` Borislav Petkov
2023-11-24 14:04 ` Greg KH
0 siblings, 1 reply; 3+ messages in thread
From: Borislav Petkov @ 2023-11-24 13:40 UTC (permalink / raw)
To: Caleb Jorden, stable; +Cc: Josh Poimboeuf, Thomas Gleixner
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
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: [Regression] Linux-6.6.2: SRSO kernel log messages incorrect
2023-11-24 13:40 ` Borislav Petkov
@ 2023-11-24 14:04 ` Greg KH
0 siblings, 0 replies; 3+ messages in thread
From: Greg KH @ 2023-11-24 14:04 UTC (permalink / raw)
To: Borislav Petkov; +Cc: Caleb Jorden, stable, Josh Poimboeuf, Thomas Gleixner
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
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2023-11-24 14:04 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2023-11-24 8:04 [Regression] Linux-6.6.2: SRSO kernel log messages incorrect Caleb Jorden
2023-11-24 13:40 ` Borislav Petkov
2023-11-24 14:04 ` Greg KH
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox