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

From: Kaplan, David

Date: Wed Dec 03 2025 - 15:14:13 EST


[AMD Official Use Only - AMD Internal Distribution Only]

> -----Original Message-----
> From: Borislav Petkov <bp@xxxxxxxxx>
> Sent: Wednesday, December 3, 2025 11:36 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 Wed, Dec 03, 2025 at 05:02:24PM +0000, Kaplan, David wrote:
> > 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...
>
> Well, we can't have the cake and eat it too - at some point the admin will
> override the setting the task did. There's no other way.
>
> > It would be cleaner if userspace never saw errors, but the mitigation were
> > just silently applied/not-applied.
>
> As in: if dynamic mitigations are enabled, kernel stops returning EPERM but
> simply overrides the mitigation setting and issues a pr_warn_once() that
> PR_SPEC_PRCTL doesn't take effect anymore due to system-wide override?
>
> Works for me...
>

Yeah, I think that's worth considering. I think for the get functions (e.g. ib_prctl_get()) they can return whatever the current mitigation status is. But for the set functions (e.g. ib_prctl_set()) would stop returning EPERM due to system-wide mitigation settings.

In other words, maybe something like this? (And similar for the other ones like ssb_prctl_seg)

diff --git a/arch/x86/kernel/cpu/bugs.c b/arch/x86/kernel/cpu/bugs.c
index 0f0e688c1fec..8b83068d0372 100644
--- a/arch/x86/kernel/cpu/bugs.c
+++ b/arch/x86/kernel/cpu/bugs.c
@@ -2859,6 +2859,7 @@ static bool is_spec_ib_user_controlled(void)
spectre_v2_user_stibp == SPECTRE_V2_USER_SECCOMP;
}

+#define PR_SPEC_MSG "PR_SET_SPECULATION_CTRL ineffective due to system-wide mitigation settings.\n"
static int ib_prctl_set(struct task_struct *task, unsigned long ctrl)
{
switch (ctrl) {
@@ -2882,10 +2883,22 @@ static int ib_prctl_set(struct task_struct *task, unsigned long ctrl)
* spectre_v2_user_ibpb == SPECTRE_V2_USER_SECCOMP and
* spectre_v2_user_stibp == SPECTRE_V2_USER_STRICT_PREFERRED.
*/
- if (!is_spec_ib_user_controlled() ||
- task_spec_ib_force_disable(task))
+ if (task_spec_ib_force_disable(task))
return -EPERM;

+ /*
+ * A system-wide mitigation setting change could render a task
+ * unable to change their mitigation options. Don't return
+ * EPERM to avoid confusion in this case.
+ */
+ if (!is_spec_ib_user_controlled()) {
+ if (!IS_ENABLED(CONFIG_DYNAMIC_MITIGATIONS))
+ return -EPERM;
+
+ pr_warn_once(PR_SPEC_MSG);
+ return 0;
+ }
+
task_clear_spec_ib_disable(task);
task_update_spec_tif(task);
break;
@@ -2896,11 +2909,16 @@ static int ib_prctl_set(struct task_struct *task, unsigned long ctrl)
* mitigation is force disabled.
*/
if (spectre_v2_user_ibpb == SPECTRE_V2_USER_NONE &&
- spectre_v2_user_stibp == SPECTRE_V2_USER_NONE)
+ spectre_v2_user_stibp == SPECTRE_V2_USER_NONE &&
+ !IS_ENABLED(CONFIG_DYNAMIC_MITIGATIONS))
return -EPERM;

- if (!is_spec_ib_user_controlled())
+ if (!is_spec_ib_user_controlled()) {
+ if (IS_ENABLED(CONFIG_DYNAMIC_MITIGATIONS))
+ pr_warn_once(PR_SPEC_MSG);
+
return 0;
+ }

task_set_spec_ib_disable(task);
if (ctrl == PR_SPEC_FORCE_DISABLE)