2023-08-19 09:21:10

by Josh Poimboeuf

[permalink] [raw]
Subject: Re: [PATCH] x86/srso: Correct the mitigation status when SMT is disabled

On Tue, Aug 15, 2023 at 10:17:53PM +0200, Borislav Petkov wrote:
> On Tue, Aug 15, 2023 at 12:58:31PM -0700, Josh Poimboeuf wrote:
> > AFAICT, nowhere in the spec does it say the SRSO_NO bit won't get set by
> > future (fixed) HW. In fact I'd expect it will, similar to other *_NO
> > flags.
>
> I'm pretty sure it won't.
>
> SRSO_NO is synthesized by the hypervisor *software*. Nothing else.

Citation needed.

> It is there so that you don't check microcode version in the guest which
> is nearly impossible anyway.
>
> > Regardless, here SRSO_NO seems to mean two different things: "reported
> > safe by host (or HW)" and "not reported safe on Zen1/2 with SMT not
> > possible".
>
> Huh?

Can you clarify what doesn't make sense?

> > Also, in this code, the SRSO_NO+SMT combo doesn't seem logically
> > possible, as srso_show_state() only gets called if X86_BUG_SRSO is set,
> > which only happens if SRSO_NO is not set by the HW/host in the first
> > place. So here, if boot_cpu_has(X86_FEATURE_SRSO_NO), it means SRSO_NO
> > was manually set by srso_select_mitigation(), and SMT can't possibly be
> > enabled.
>
> Have you considered the case where Linux would set SRSO_NO when booting
> on future hardware, which is fixed?
>
> There SRSO_NO and SMT will very much be possible.

How is that relevant to my comment? The bug bit still wouldn't get set
and srso_show_state() still wouldn't be called.

--
Josh


2023-08-19 11:59:22

by Borislav Petkov

[permalink] [raw]
Subject: Re: [PATCH] x86/srso: Correct the mitigation status when SMT is disabled

On Tue, Aug 15, 2023 at 02:27:51PM -0700, Josh Poimboeuf wrote:
> How is that relevant to my comment? The bug bit still wouldn't get set
> and srso_show_state() still wouldn't be called.

Lemme explain how I see this working - it might help us get on the right
track. And for comparison you can look at X86_FEATURE_BTC_NO too.

* Something has set X86_FEATURE_SRSO_NO - hw or sw doesn't matter
- because the machine is not affected. X86_BUG_SRSO doesn't get set and
the mitigation detection is skipped. All good.

* Nothing has set X86_FEATURE_SRSO_NO, mitigation detection runs and
find that the kernel runs on a Zen1/2 with SMT disabled - we set
X86_FEATURE_SRSO_NO.

* Now X86_FEATURE_SRSO_NO is passed in by KVM to the guest and the above
dance repeats.

Now you.

--
Regards/Gruss,
Boris.

https://people.kernel.org/tglx/notes-about-netiquette