linux-kernel - Re: [RFC PATCH 07/56] x86/bugs: Reset spectre_v2

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] [day] [month] [year] [list]

Message-ID: <20251126112320.GNaSbjKPpKWNRLDLwP@fat_crate.local>
Date: Wed, 26 Nov 2025 12:23:20 +0100
From: Borislav Petkov <bp@...en8.de>
To: Brendan Jackman <jackmanb@...gle.com>
Cc: "Kaplan, David" <David.Kaplan@....com>,
	Thomas Gleixner <tglx@...utronix.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>, Alexander Graf <graf@...zon.com>,
	Boris Ostrovsky <boris.ostrovsky@...cle.com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [RFC PATCH 07/56] x86/bugs: Reset spectre_v2_user mitigations

On Thu, Oct 16, 2025 at 04:13:25PM +0000, Brendan Jackman wrote:
> This seems a bit over-complicated though, in practice it seems pretty
> likely that just hitting people with the unexpected errors is sort of
> OK? At least for the usecase I'm seeing everything through the lens of,
> I think it would be. 

Yah, this topic does get my brain in a twist...

But I think I know what the right thing to do here should be:

If the admin goes and dynamically changes mitigation settings, no matter what
processes have selected previously, their settings will be changed once they
go through cond_mitigation().

If what userspace has selected previously and if that selection is not
compatible with what the dynamic, system-wide mitigation setting got changed
to, then the per-process setting will get changed.

Because the admin wanted it so and the admin can do anything. It is basically
the same as any other OS resource change - userspace needs to handle it and
adjust to it.

If the admin decides that the system wants to force mitigations on, then all
processes will have to comply. It is what it is.

It'll need a proper audit of all the TIF_SPEC_ and other flags and we would
have to even override them and issue warnings why we do so.

But I'm thinking: if the admin changes system-wide settings, the only right
thing for tasks is to comply.

I'd say.

-- 
Regards/Gruss,
    Boris.

https://people.kernel.org/tglx/notes-about-netiquette