Messages in this thread | | | Date | Tue, 15 Aug 2023 14:27:51 -0700 | From | Josh Poimboeuf <> | 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
| |