Re: [PATCH v3 21/35] x86/bugs: Determine relevant vulnerabilities based on attack vector controls.

[Josh Poimboeuf]

On Tue, Feb 11, 2025 at 10:41:33AM -0800, Josh Poimboeuf wrote:
> I'm confused by CPU_MITIGATE_CROSS_THREAD here, as the GDS mitigation
> doesn't seem to disable SMT?
> 
> Am I just completely misunderstanding the meaning of
> CPU_MITIGATE_CROSS_THREAD?
> 
> I assumed it's not a vector per se, but rather it means to force nosmt
> if one of the other enabled mitigations requires doing so for its "full"
> mitigation.  But the implementation doesn't seem to match that.
> 
> On the other hand if it really is considered to be its own vector, that
> doesn't make sense either, as "cross-thread attack" is really a subset
> of each of the other vectors.  For example, a user->kernel attack can
> often be done either via syscall/irq or via cross-thread.
> 
> So I'm really confused.  Am I missing something?

So I looked at the next patch and now I see what I was missing: the
individual mitigations are checking
cpu_mitigate_attack_vector(CPU_MITIGATE_CROSS_THREAD) before deciding
whether to disable SMT.  So the implementation mostly makes sense now.

should_mitigate_vuln() should have a comment at the top explaining that
it doesn't check CPU_MITIGATE_CROSS_THREAD (since it's not actually a
standalone vector but rather dependent on the others) and that each
individual mitigation should check CPU_MITIGATE_CROSS_THREAD when
deciding whether to disable SMT.

Also, checking CPU_MITIGATE_CROSS_THREAD for GDS doesn't make sense
because as I mentioned above, "cross-thread" is really a subset of the
other vectors.  If the user isn't concerned about any of the other
attack vectors, mitigate_cross_thread=on should just be ignored.

I'm also thinking that "mitigate_cross_thread" isn't quite the right
name for it, as it really only relates to disabling SMT rather than
other cross-thread mitigations like STIBP.

So "mitigate_disable_smt" or "mitigate_nosmt"?

-- 
Josh