Re: [PATCH v5 01/16] x86/bugs: Restructure MDS mitigation

Borislav Petkov
2025-04-22T08:18:19Z

On Sun, Apr 20, 2025 at 09:00:56PM +0000, Kaplan, David wrote:
> I'm not sure this is right, it certainly diverges from upstream where
> mds is only marked as mitigated if the CPU is actually vulnerable to
> mds. I also think that imo it generally does not make sense to mark
> a bug as mitigated if the CPU isn't vulnerable (seems to increase risk
> of future bugs in the logic).

Hmm, it still looks weird to me. So let's imagine the CPU is NOT
affected by MDS. The select function will leave it to OFF.

Then, some other select function will set verw_mitigation_selected.

Now, the mds_update_mitigation() comes in, X86_BUG_MDS is still NOT set
so we leave mds_mitigation to OFF even though it *technically* gets
mitigated?

I guess the reporting aspect does make sense - we don't want to start
reporting MDS-unaffected CPUs as being MDS mitigated because they're not
- not really. We just use their mitigation to mitigate other vulns.

Then this comment which explains the logic of verw_mitigation_selected:

/* If TAA, MMIO, or RFDS are being mitigated, MDS gets mitigated too. */

should probably say that if the CPU is affected by MDS *in any way*
- the BUG bit is set - then it gets full mitigation.

And this should be the case for all inter-related VERW mitigations: if
the CPU is in any way affected, it gets mitigated too. If it is not,
then it gets only *reported* that it is not affected but the mitigation
technique can be used for others.

Does that make sense?

I'm basically thinking out loud here, trying to explain (to myself
mostly:)) how this verw_mitigation_selected is going to be employed.

Thx.

--
Regards/Gruss,
Boris.