| 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
| ||
|
Message-ID:
<LV3PR12MB92655023C50A92BE30D7A8049438A@LV3PR12MB9265.namprd12.prod.outlook.com>
Date: Wed, 27 Aug 2025 14:05:14 +0000
From: "Kaplan, David" <David.Kaplan@....com>
To: Borislav Petkov <bp@...en8.de>, Pawan Gupta
<pawan.kumar.gupta@...ux.intel.com>
CC: Thomas Gleixner <tglx@...utronix.de>, Peter Zijlstra
<peterz@...radead.org>, Josh Poimboeuf <jpoimboe@...nel.org>, Ingo Molnar
<mingo@...hat.com>, Dave Hansen <dave.hansen@...ux.intel.com>,
"x86@...nel.org" <x86@...nel.org>, "H . Peter Anvin" <hpa@...or.com>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: RE: [PATCH v2 4/5] x86/bugs: Add attack vector controls for SSB
[AMD Official Use Only - AMD Internal Distribution Only]
> -----Original Message-----
> From: Borislav Petkov <bp@...en8.de>
> Sent: Wednesday, August 27, 2025 6:04 AM
> To: Pawan Gupta <pawan.kumar.gupta@...ux.intel.com>; Kaplan, David
> <David.Kaplan@....com>
> Cc: Thomas Gleixner <tglx@...utronix.de>; Peter Zijlstra <peterz@...radead.org>;
> Josh Poimboeuf <jpoimboe@...nel.org>; Ingo Molnar <mingo@...hat.com>; Dave
> Hansen <dave.hansen@...ux.intel.com>; x86@...nel.org; H . Peter Anvin
> <hpa@...or.com>; linux-kernel@...r.kernel.org
> Subject: Re: [PATCH v2 4/5] x86/bugs: Add attack vector controls for SSB
>
> Caution: This message originated from an External Source. Use proper caution
> when opening attachments, clicking links, or responding.
>
>
> On Wed, Aug 27, 2025 at 12:27:54PM +0200, Borislav Petkov wrote:
> > Fixed and expediting this one so that 6.17 releases with the full attack
> > vectors functionality.
>
> Ok, so I'm thinking we should do a minimal fix like this below which goes to
> Linus now so that 6.17 has full attack vectors support and then slap
> all cleanups ontop. Thoughts?
>
> ---
> From: David Kaplan <david.kaplan@....com>
> Date: Tue, 19 Aug 2025 14:21:59 -0500
> Subject: [PATCH] x86/bugs: Add attack vector controls for SSB
>
> Attack vector controls for SSB were missed in the initial attack vector series.
> The default mitigation for SSB requires user-space opt-in so it is only
> relevant for user->user attacks. Add an AUTO mitigation for SSB and use this
> attack vector control to select the SSB mitigation.
>
> Fixes: 2d31d2874663 ("x86/bugs: Define attack vectors relevant for each bug")
> Signed-off-by: David Kaplan <david.kaplan@....com>
> Signed-off-by: Borislav Petkov (AMD) <bp@...en8.de>
> Reviewed-by: Pawan Gupta <pawan.kumar.gupta@...ux.intel.com>
> Link: https://lore.kernel.org/20250819192200.2003074-5-david.kaplan@amd.com
> ---
> .../hw-vuln/attack_vector_controls.rst | 5 +----
> arch/x86/include/asm/nospec-branch.h | 1 +
> arch/x86/kernel/cpu/bugs.c | 15 ++++++++++++++-
> 3 files changed, 16 insertions(+), 5 deletions(-)
>
> diff --git a/Documentation/admin-guide/hw-vuln/attack_vector_controls.rst
> b/Documentation/admin-guide/hw-vuln/attack_vector_controls.rst
> index 6dd0800146f6..5964901d66e3 100644
> --- a/Documentation/admin-guide/hw-vuln/attack_vector_controls.rst
> +++ b/Documentation/admin-guide/hw-vuln/attack_vector_controls.rst
> @@ -215,7 +215,7 @@ Spectre_v2 X X
> Spectre_v2_user X X * (Note 1)
> SRBDS X X X X
> SRSO X X X X
> -SSB (Note 4)
> +SSB X
> TAA X X X X * (Note 2)
> TSA X X X X
> =============== ============== ============ =============
> ============== ============ ========
> @@ -229,9 +229,6 @@ Notes:
> 3 -- Disables SMT if cross-thread mitigations are fully enabled, the CPU is
> vulnerable, and STIBP is not supported
>
> - 4 -- Speculative store bypass is always enabled by default (no kernel
> - mitigation applied) unless overridden with spec_store_bypass_disable option
> -
> When an attack-vector is disabled, all mitigations for the vulnerabilities
> listed in the above table are disabled, unless mitigation is required for a
> different enabled attack-vector or a mitigation is explicitly selected via a
> diff --git a/arch/x86/include/asm/nospec-branch.h b/arch/x86/include/asm/nospec-
> branch.h
> index 10f261678749..e263c126723a 100644
> --- a/arch/x86/include/asm/nospec-branch.h
> +++ b/arch/x86/include/asm/nospec-branch.h
> @@ -514,6 +514,7 @@ enum spectre_v2_user_mitigation {
> /* The Speculative Store Bypass disable variants */
> enum ssb_mitigation {
> SPEC_STORE_BYPASS_NONE,
> + SPEC_STORE_BYPASS_AUTO,
> SPEC_STORE_BYPASS_DISABLE,
> SPEC_STORE_BYPASS_PRCTL,
> SPEC_STORE_BYPASS_SECCOMP,
> diff --git a/arch/x86/kernel/cpu/bugs.c b/arch/x86/kernel/cpu/bugs.c
> index 49ef1b832c1a..159beed05ee8 100644
> --- a/arch/x86/kernel/cpu/bugs.c
> +++ b/arch/x86/kernel/cpu/bugs.c
> @@ -416,6 +416,10 @@ static bool __init should_mitigate_vuln(unsigned int bug)
> cpu_attack_vector_mitigated(CPU_MITIGATE_USER_USER) ||
> cpu_attack_vector_mitigated(CPU_MITIGATE_GUEST_GUEST) ||
> (smt_mitigations != SMT_MITIGATIONS_OFF);
> +
> + case X86_BUG_SPEC_STORE_BYPASS:
> + return cpu_attack_vector_mitigated(CPU_MITIGATE_USER_USER);
> +
> default:
> WARN(1, "Unknown bug %x\n", bug);
> return false;
> @@ -2619,7 +2623,8 @@ void cpu_bugs_smt_update(void)
> #undef pr_fmt
> #define pr_fmt(fmt) "Speculative Store Bypass: " fmt
>
> -static enum ssb_mitigation ssb_mode __ro_after_init =
> SPEC_STORE_BYPASS_NONE;
> +static enum ssb_mitigation ssb_mode __ro_after_init =
> + IS_ENABLED(CONFIG_MITIGATION_SSB) ?
> SPEC_STORE_BYPASS_AUTO : SPEC_STORE_BYPASS_NONE;
>
> /* The kernel command line selection */
> enum ssb_mitigation_cmd {
> @@ -2695,6 +2700,13 @@ static void __init ssb_select_mitigation(void)
> cmd == SPEC_STORE_BYPASS_CMD_AUTO))
> return;
>
> + if (ssb_mode == SPEC_STORE_BYPASS_AUTO) {
> + if (should_mitigate_vuln(X86_BUG_SPEC_STORE_BYPASS))
> + ssb_mode = SPEC_STORE_BYPASS_PRCTL;
> + else
> + ssb_mode = SPEC_STORE_BYPASS_NONE;
> + }
> +
> switch (cmd) {
> case SPEC_STORE_BYPASS_CMD_SECCOMP:
> /*
> @@ -2935,6 +2947,7 @@ static int ssb_prctl_get(struct task_struct *task)
> return PR_SPEC_DISABLE;
> case SPEC_STORE_BYPASS_SECCOMP:
> case SPEC_STORE_BYPASS_PRCTL:
> + case SPEC_STORE_BYPASS_AUTO:
> if (task_spec_ssb_force_disable(task))
> return PR_SPEC_PRCTL | PR_SPEC_FORCE_DISABLE;
> if (task_spec_ssb_noexec(task))
> --
> 2.51.0
>
This patch won't work if you don't pick up the SSB clean-up (patch #3). The SSB clean-up patch removes the ssb_mitigation_cmd and makes all selection on ssb_mode, which is simpler and allows the attack vector control to easily work.
In the above code, ssb_mode is always SPEC_STORE_BYPASS_AUTO when ssb_select_mitigation() runs. But then ssb_mode will be overwritten by the switch statement later. In particular, if no cmdline option is passed, the cmd will be SPEC_STORE_BYPASS_CMD_AUTO which in the switch statement always sets mode to SPEC_STORE_BYPASS_PRCTL, ignoring the attack vector.
If you really want to not pick up patch #3 yet, then you could move the should_mitigate_vuln() check into the switch statement for SPEC_STORE_BYPASS_CMD_AUTO only. Or just pick up the clean-up patch which also reduces the overall code size.
--David Kaplan
Powered by blists - more mailing lists