Messages in this thread | | | Date | Tue, 15 Aug 2023 22:17:53 +0200 | From | Borislav Petkov <> | Subject | Re: [PATCH] x86/srso: Correct the mitigation status when SMT is disabled |
| |
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.
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?
> 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.
> Instead of piggybacking on SRSO_NO, which is confusing, why not just add > a new mitigation type, like:
I had a separate mitigation defintion but then realized I don't need it because, well, it is not really a mitigation - it is a case where the machine is not affected.
For example, I have a Zen2 laptop here with SMT disabled in the hardware which is also not affected.
And also, the rest of the SMT disabled cases in bugs.c do check sched_smt_active() too, without having a separate mitigation.
That's why.
-- Regards/Gruss, Boris.
https://people.kernel.org/tglx/notes-about-netiquette
| |