linux-kernel - Re: [PATCH v3 06/35] x86/bugs: Restructure mmio mitigation

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CA+i-1C0mMOSfycSMjpxhX_ARubx140dHb39FJ07FvR2rUOiK4Q@mail.gmail.com>
Date: Mon, 10 Feb 2025 18:35:39 +0100
From: Brendan Jackman <jackmanb@...gle.com>
To: "Kaplan, David" <David.Kaplan@....com>
Cc: Thomas Gleixner <tglx@...utronix.de>, Borislav Petkov <bp@...en8.de>, 
	Peter Zijlstra <peterz@...radead.org>, Josh Poimboeuf <jpoimboe@...nel.org>, 
	Pawan Gupta <pawan.kumar.gupta@...ux.intel.com>, Ingo Molnar <mingo@...hat.com>, 
	Dave Hansen <dave.hansen@...ux.intel.com>, "x86@...nel.org" <x86@...nel.org>, 
	"H . Peter Anvin" <hpa@...or.com>, 
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v3 06/35] x86/bugs: Restructure mmio mitigation

On Mon, 10 Feb 2025 at 18:22, Kaplan, David <David.Kaplan@....com> wrote:
> > This is still peeking at other mitigations in _apply_mitigation.
> > Shouldn't we shunt that logic into _update_mitigation?
> >
> > I guess this would need a new enum value but that doesn't seem too bad. Worth it
> > to have all the inter-mitigation dependencies localised into *_udpate_mitigation IMO.
>
> I don't think it is peeking at other mitigations, it's only looking at what other bugs the CPU has (which is static).  Looking at the mds/taa/etc. mitigation values is done in mmio_update_mitigation.

Hmm, that's true but it doesn't quite shake my underlying feeling that
we're leaving isolation of logic on the table here. I know I said
"inter-mitigation dependencies" but if we could even keep all the
inter-_vuln_ dependencies in one place that would be really nice.

But, I will come back to this once I've looked at the rest of the
series. Maybe it doesn't really make sense to try and fully isolate
these things.