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:
 <LV3PR12MB9265911DCCAB57AFB4C4660294DBA@LV3PR12MB9265.namprd12.prod.outlook.com>
Date: Mon, 1 Dec 2025 16:53:58 +0000
From: "Kaplan, David" <David.Kaplan@....com>
To: Borislav Petkov <bp@...en8.de>, Brendan Jackman <jackmanb@...gle.com>
CC: 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

[AMD Official Use Only - AMD Internal Distribution Only]

> -----Original Message-----
> From: Borislav Petkov <bp@...en8.de>
> Sent: Wednesday, November 26, 2025 5:23 AM
> 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; H . Peter
> Anvin <hpa@...or.com>; Alexander Graf <graf@...zon.com>; Boris
> Ostrovsky <boris.ostrovsky@...cle.com>; linux-kernel@...r.kernel.org
> Subject: Re: [RFC PATCH 07/56] x86/bugs: Reset spectre_v2_user mitigations
>
> Caution: This message originated from an External Source. Use proper
> caution when opening attachments, clicking links, or responding.
>
>
> 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.
>

What does it mean for a 'task to comply'?

I think it's one thing for the task to ask for a mitigation and then the admin goes and overrides it with a system-wide setting.  That doesn't worry me too much...the admin should be able to do that.  If it's just a mater of enabling/disabling some mitigation feature, that doesn't affect the functionality of the process and it can be rather transparently done.

But this particular interface is tricky because it returns EPERM in some cases, like when the task asks for something but the admin doesn't allow it.  In theory you could have processes that don't expect to see such an error in the middle of execution...that is, they might try to configure settings initially, find that succeeds, and then later modify them and not expect them to fail.  Brendan is saying maybe that's ok, are you aligned with that?

If so, I don't think we really have to do anything special then...the behavior of this prctl() may change due to dynamic mitigation changes and userspace might see unexpected EPERM errors if that happens.

--David Kaplan