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:
 <LV3PR12MB9265F2495AC34F035F2723AB94D9A@LV3PR12MB9265.namprd12.prod.outlook.com>
Date: Wed, 3 Dec 2025 17:02:24 +0000
From: "Kaplan, David" <David.Kaplan@....com>
To: Borislav Petkov <bp@...en8.de>
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

[AMD Official Use Only - AMD Internal Distribution Only]

> -----Original Message-----
> From: Borislav Petkov <bp@...en8.de>
> Sent: Wednesday, December 3, 2025 6:31 AM
> 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; 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 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...?
>

We don't know how tasks are using this prctl().  Maybe the task only sets PR_SPEC_DISABLE around one specific function call.

What if a program starts up and queries the kernel and gets PR_SPEC_PRCTL so it thinks it can control things.  And then it calls PR_SPEC_DISABLE/PR_SPEC_ENABLE around one particular sensitive function.

And then at some point, it starts getting -EPERM...

It would be cleaner if userspace never saw errors, but the mitigation were just silently applied/not-applied.

--David Kaplan