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

Message-ID: <20251203123125.GAaTAtneKj5v1OaqtS@fat_crate.local>
Date: Wed, 3 Dec 2025 13:31:25 +0100
From: Borislav Petkov <bp@...en8.de>
To: "Kaplan, David" <David.Kaplan@....com>
Cc: Brendan Jackman <jackmanb@...gle.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 Mon, Dec 01, 2025 at 04:53:58PM +0000, Kaplan, David wrote:
> What does it mean for a 'task to comply'?

If the task has selected a mitigation which is not compatible with the setting
the admin selected later, that task's mitigation settings will be changed when
it goes through __switch_to.

> 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. 

Ack.

> 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?

No, not in the middle of execution - their mitigation setting will get changed
when they get scheduled. Example:

1. task sets PR_SPEC_DISABLE and enables indirect branches for it
2. admin comes in and disables indirect branches system-wide - i.e.,
   SPECTRE_V2_USER_STRICT.
3. task comes through schedule() and it gets PR_SPEC_ENABLE forced on it

Makes sense?

> 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.

I'm thinking the task will run the prctl() when it starts. Then, after the
system-wide setting has been changed, the above will happen.

A *new* task will then see EPERM and should be able to handle it.

Or am I missing a case...?

Thx.

-- 
Regards/Gruss,
    Boris.

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