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 for Android: free password hash cracker in your pocket
[<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

Powered by Openwall GNU/*/Linux Powered by OpenVZ