[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID:
<LV3PR12MB92651503DE2CB38207D1E55A94D9A@LV3PR12MB9265.namprd12.prod.outlook.com>
Date: Wed, 3 Dec 2025 20:14:08 +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 11:36 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 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)
Powered by blists - more mailing lists