RE: [RFC PATCH 07/56] x86/bugs: Reset spectre_v2_user mitigations

[Kaplan, David]

[AMD Official Use Only - AMD Internal Distribution Only]

> -----Original Message-----
> From: Borislav Petkov <bp@xxxxxxxxx>
> Sent: Wednesday, December 3, 2025 6:31 AM
> To: Kaplan, David <David.Kaplan@xxxxxxx>
> Cc: Brendan Jackman <jackmanb@xxxxxxxxxx>; Thomas Gleixner
> <tglx@xxxxxxxxxxxxx>; Peter Zijlstra <peterz@xxxxxxxxxxxxx>; Josh Poimboeuf
> <jpoimboe@xxxxxxxxxx>; Pawan Gupta
> <pawan.kumar.gupta@xxxxxxxxxxxxxxx>; Ingo Molnar <mingo@xxxxxxxxxx>;
> Dave Hansen <dave.hansen@xxxxxxxxxxxxxxx>; x86@xxxxxxxxxx; H . Peter
> Anvin <hpa@xxxxxxxxx>; Alexander Graf <graf@xxxxxxxxxx>; Boris
> Ostrovsky <boris.ostrovsky@xxxxxxxxxx>; linux-kernel@xxxxxxxxxxxxxxx
> 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