Message ID | 20230813104517.3346-1-bp@alien8.de |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a59:b824:0:b0:3f2:4152:657d with SMTP id z4csp2142553vqi; Sun, 13 Aug 2023 04:03:59 -0700 (PDT) X-Google-Smtp-Source: AGHT+IFHnSWmLrDA2IlQvVUYJSJAXy7dwyyYjqP4psmfe3zvTpYNI5lLD2cebpu5npfGY7bhemw6 X-Received: by 2002:a05:6a00:15d6:b0:641:3bf8:6514 with SMTP id o22-20020a056a0015d600b006413bf86514mr9064806pfu.10.1691924639416; Sun, 13 Aug 2023 04:03:59 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1691924639; cv=none; d=google.com; s=arc-20160816; b=uBlY7fi9xsNJf1yW7G1VFrkqGIsYwbTaA1UPDLfm4TMlDnPj7BItBD0/fqO45DyQuV KYovvzVs4yZrY1SKTvzktJaX9REnNULCCAqZlYCtJQdLvARmSOtTKSLhHlMg0pocsXS0 l7dqzudNFgGOEERFF2sYHdvQt3PUwUNwNR2MXT75C7LbSfvrSgV365nd+fukVSWhjEJw imEeEoZyn8573ThoxIhxcWLi2vhYRLa2/9PhqUP2Frx1r1c/2FyMx9Be5ttw7Eb2Ze7t SGjxT8TTkFcjp35nYoYOCBYJFoaKNPvPntb3kCR/rwZ98j7G1ZupHBSirFcvBEOAxTbE +ltg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :message-id:date:subject:cc:to:from:dkim-signature; bh=aUD/SrnUMCQ+ZXXzepPUtv3zTRZ1dpzfeWKcxXP6mbM=; fh=ArBSoxdtZ/33GNivUrPswxBO7jysKOxoXLVWjB2CEZc=; b=0zRpPlOhbNpeAGQD1uEcsQ0EFkTAq+XRU0OvE959Md+6ABgqeC3Y1gXnKuar6mtOhV V3g/eI2/k0xk3NgLszyHVE839V1IC3Pg95JQYcrYjHnwbioTf1dGZfK1Ed5pIJyxZZ9+ twVIneJvK8nG1Aipcj0BAVV2MyXTC8SlOKK9Y0F7A2cY2E2V5Cho7RDVrzpi6HAO8V28 sroGXT1mRpPcMW3tbLVQGqUeWjpDhU7lbvoROF5Qjb4oexxT5DjYLiNPtFyRlh5VsCz3 XKUrL+9awGWM9l8I5W7QaNdEXCBSh7pr+WUHxrb+kVNbdGqCdnzvvETKSnvRvylnwlav O9Uw== ARC-Authentication-Results: i=1; mx.google.com; dkim=neutral (body hash did not verify) header.i=@alien8.de header.s=alien8 header.b=OBAHQWv2; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=alien8.de Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id m11-20020a056a00080b00b006871817f76dsi6494536pfk.202.2023.08.13.04.03.45; Sun, 13 Aug 2023 04:03:59 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=neutral (body hash did not verify) header.i=@alien8.de header.s=alien8 header.b=OBAHQWv2; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=alien8.de Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229931AbjHMKp1 (ORCPT <rfc822;274620705z@gmail.com> + 99 others); Sun, 13 Aug 2023 06:45:27 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:48086 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229480AbjHMKpZ (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Sun, 13 Aug 2023 06:45:25 -0400 Received: from mail.alien8.de (mail.alien8.de [65.109.113.108]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id EB7711709 for <linux-kernel@vger.kernel.org>; Sun, 13 Aug 2023 03:45:26 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.alien8.de (SuperMail on ZX Spectrum 128k) with ESMTP id 10E1340E0196; Sun, 13 Aug 2023 10:45:25 +0000 (UTC) X-Virus-Scanned: Debian amavisd-new at mail.alien8.de Authentication-Results: mail.alien8.de (amavisd-new); dkim=fail (4096-bit key) reason="fail (body has been altered)" header.d=alien8.de Received: from mail.alien8.de ([127.0.0.1]) by localhost (mail.alien8.de [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id WqiI0bQmSuBk; Sun, 13 Aug 2023 10:45:23 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=alien8.de; s=alien8; t=1691923522; bh=qVnzDGNq3+H6zNvRihhqRbRt0S9chv07HAXr7d9v75U=; h=From:To:Cc:Subject:Date:From; b=OBAHQWv2Di5wVFVoDKhrWpf5Xr0OeZLMrsViu+Ly9d2fchsPbiuVY8JHHHktz6eNE TxVYTTQhc3BG3zY9Cy5iIfQohQQhl6vbNvGR5Sc74j32lgjCDzCknm1IDzefA5IbuO esKBPEZhkjTDgpvnH5tZpw6CiEZxinJtvS0TwCcaAIOui2wiNEE1ZRzqBD6Tkt3HET KE+imenDRPLN2nlZ1mU7Dn+Ib0M3qiI8PQk0+fdPvnniWepNU9dGP0gFEP4+gpui+R +3aOUhFRH82oLjaVaQIGo2d566PhD6Ny8GE98uIWvbTRcRQi3BcrvHYlP8/r1Aj+e7 RxU75XNNPVmr8/tymZ4ORU6lXnKKXgAb9hELEsdPMvBwxD8ekzBDgOCdo0wAPDs+37 DLFP1kmNcbNw3gQ3FRhrfvr4wZjaURXhuX9A06WxInZLrSn8kzetFtzclwJod77rw3 pHcI6ynj9EK5L8vq+FwBOJ+8AlHgiNg8f6TiCdSPWTsTP8k/XHaQ++tbtaGr5+VCkN TxEGif8+cxdwPb5zVLeXjL0PixF89RG/6v8oEf9oUUjDoRstMzXX2oK2GNdYaEoCH4 aVWxxH9mM+OMZypom2G6418w3C4GzL6ZPiN4NyPkHU8Y56uy7rtjGyqSEOwynJ5xE7 /OECq7MLJWRQNeduoOq/0yX8= Received: from zn.tnic (pd9530d32.dip0.t-ipconnect.de [217.83.13.50]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature ECDSA (P-256) server-digest SHA256) (No client certificate requested) by mail.alien8.de (SuperMail on ZX Spectrum 128k) with ESMTPSA id 4FA2E40E0195; Sun, 13 Aug 2023 10:45:19 +0000 (UTC) From: Borislav Petkov <bp@alien8.de> To: X86 ML <x86@kernel.org> Cc: Josh Poimboeuf <jpoimboe@redhat.com>, LKML <linux-kernel@vger.kernel.org> Subject: [PATCH] x86/srso: Disable the mitigation on unaffected configurations Date: Sun, 13 Aug 2023 12:45:17 +0200 Message-ID: <20230813104517.3346-1-bp@alien8.de> X-Mailer: git-send-email 2.42.0.rc0.25.ga82fb66fed25 MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-1.7 required=5.0 tests=BAYES_00,DKIM_INVALID, DKIM_SIGNED,SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: <linux-kernel.vger.kernel.org> X-Mailing-List: linux-kernel@vger.kernel.org X-getmail-retrieved-from-mailbox: INBOX X-GMAIL-THRID: 1774111570858746756 X-GMAIL-MSGID: 1774111570858746756 |
Series |
x86/srso: Disable the mitigation on unaffected configurations
|
|
Commit Message
Borislav Petkov
Aug. 13, 2023, 10:45 a.m. UTC
From: "Borislav Petkov (AMD)" <bp@alien8.de> Skip the srso cmd line parsing which is not needed on Zen1/2 with SMT disabled and with the proper microcode applied (latter should be the case anyway) as those are not affected. Fixes: 5a15d8348881 ("x86/srso: Tie SBPB bit setting to microcode patch detection") Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de> --- arch/x86/kernel/cpu/bugs.c | 7 ++++++- 1 file changed, 6 insertions(+), 1 deletion(-)
Comments
On 13.08.23 г. 13:45 ч., Borislav Petkov wrote: > From: "Borislav Petkov (AMD)" <bp@alien8.de> > > Skip the srso cmd line parsing which is not needed on Zen1/2 with SMT > disabled and with the proper microcode applied (latter should be the > case anyway) as those are not affected. > > Fixes: 5a15d8348881 ("x86/srso: Tie SBPB bit setting to microcode patch detection") > Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de> > --- > arch/x86/kernel/cpu/bugs.c | 7 ++++++- > 1 file changed, 6 insertions(+), 1 deletion(-) > > diff --git a/arch/x86/kernel/cpu/bugs.c b/arch/x86/kernel/cpu/bugs.c > index d02f73c5339d..8959a1b9fb80 100644 > --- a/arch/x86/kernel/cpu/bugs.c > +++ b/arch/x86/kernel/cpu/bugs.c > @@ -2418,8 +2418,10 @@ static void __init srso_select_mitigation(void) > * IBPB microcode has been applied. > */ > if ((boot_cpu_data.x86 < 0x19) && > - (!cpu_smt_possible() || (cpu_smt_control == CPU_SMT_DISABLED))) > + (!cpu_smt_possible() || (cpu_smt_control == CPU_SMT_DISABLED))) { > setup_force_cpu_cap(X86_FEATURE_SRSO_NO); > + goto pred_cmd; Actually can't you simply return, given that zen1/2 never have the SBPB flag set? Only zen3/4 with the updated microcode? > + } > } > > if (retbleed_mitigation == RETBLEED_MITIGATION_IBPB) { > @@ -2696,6 +2698,9 @@ static ssize_t retbleed_show_state(char *buf) > > static ssize_t srso_show_state(char *buf) > { > + if (boot_cpu_has(X86_FEATURE_SRSO_NO)) > + return sysfs_emit(buf, "Not affected\n"); > + > return sysfs_emit(buf, "%s%s\n", > srso_strings[srso_mitigation], > (cpu_has_ibpb_brtype_microcode() ? "" : ", no microcode"));
On Mon, Aug 14, 2023 at 09:39:11AM +0300, Nikolay Borisov wrote: > > > On 13.08.23 г. 13:45 ч., Borislav Petkov wrote: > > From: "Borislav Petkov (AMD)" <bp@alien8.de> > > > > Skip the srso cmd line parsing which is not needed on Zen1/2 with SMT > > disabled and with the proper microcode applied (latter should be the > > case anyway) as those are not affected. > > > > Fixes: 5a15d8348881 ("x86/srso: Tie SBPB bit setting to microcode patch detection") > > Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de> > > --- > > arch/x86/kernel/cpu/bugs.c | 7 ++++++- > > 1 file changed, 6 insertions(+), 1 deletion(-) > > > > diff --git a/arch/x86/kernel/cpu/bugs.c b/arch/x86/kernel/cpu/bugs.c > > index d02f73c5339d..8959a1b9fb80 100644 > > --- a/arch/x86/kernel/cpu/bugs.c > > +++ b/arch/x86/kernel/cpu/bugs.c > > @@ -2418,8 +2418,10 @@ static void __init srso_select_mitigation(void) > > * IBPB microcode has been applied. > > */ > > if ((boot_cpu_data.x86 < 0x19) && > > - (!cpu_smt_possible() || (cpu_smt_control == CPU_SMT_DISABLED))) > > + (!cpu_smt_possible() || (cpu_smt_control == CPU_SMT_DISABLED))) { > > setup_force_cpu_cap(X86_FEATURE_SRSO_NO); > > + goto pred_cmd; > > Actually can't you simply return, given that zen1/2 never have the SBPB flag > set? Only zen3/4 with the updated microcode? Tangentially, the 'cpu_smt_control == CPU_SMT_DISABLED' check is wrong, as SMT could still get enabled at runtime and SRSO would be exposed. Also is there a reason to re-use the hardware SRSO_NO bit rather than clear the bug bit? That seems cleaner, then you wouldn't need this hack: > > + if (boot_cpu_has(X86_FEATURE_SRSO_NO)) > > + return sysfs_emit(buf, "Not affected\n"); > > +
On Mon, Aug 14, 2023 at 10:25:45PM +0200, Borislav Petkov wrote: > On Mon, Aug 14, 2023 at 01:08:13PM -0700, Josh Poimboeuf wrote: > > Tangentially, the 'cpu_smt_control == CPU_SMT_DISABLED' check is wrong, > > as SMT could still get enabled at runtime and SRSO would be exposed. > > Well, even if it gets exposed, I don't think we can safely enable the > mitigation at runtime as alternatives have run already. Right, I wasn't suggesting to enable the mitigation at runtime. Rather, enable the mitigation at boot time, if SMT is even possible. That's what we've done for other mitigations. Better safe than sorry. > I guess I could use CPU_SMT_FORCE_DISABLED here. cpu_smt_possible() already does that. > > Also is there a reason to re-use the hardware SRSO_NO bit > > Not a hardware bit - this is set by software - it is only allocated in > the CPUID leaf for easier interaction with guests. 2. ENUMERATION OF NEW CAPABILITIES AMD is defining three new CPUID bits to assist with the enumeration of capabilities related to SRSO: CPUID Fn8000_0021_EAX[29] (SRSO_NO) – If this bit is 1, it indicates the CPU is not subject to the SRSO vulnerability. CPUID Fn8000_0021_EAX[28] (IBPB_BRTYPE) – If this bit is 1, it indicates that MSR 49h (PRED_CMD) bit 0 (IBPB) flushes all branch type predictions from the CPU branch predictor. CPUID Fn8000_0021_EAX[27] (SBPB) > > rather than clear the bug bit? > > We don't clear the X86_BUGs. Ever. The logic is that if the CPU matches > an affected CPU, that flag remains to show that it is potentially > affected. Hm, ok. I thought that was the point of the vulnerabilities file. > /sys/devices/system/cpu/vulnerabilities/ tells you what the actual state > is. Since technically the CPU is affected, I'm thinking it should say "Mitigation: SMT disabled" or such, instead of "Not affected". > > That seems cleaner, then you wouldn't need this hack: > > Not a hack. This is just like the other "not affected" feature flags. Hm? You mean the *_NO ones that determine whether the BUG bits get set in the first place? How do they print "Not affected"?
On Tue, Aug 15, 2023 at 11:57:24AM +0200, Borislav Petkov wrote: > --- a/arch/x86/kernel/cpu/bugs.c > +++ b/arch/x86/kernel/cpu/bugs.c > @@ -2417,8 +2417,7 @@ static void __init srso_select_mitigation(void) > * Zen1/2 with SMT off aren't vulnerable after the right > * IBPB microcode has been applied. > */ > - if ((boot_cpu_data.x86 < 0x19) && > - (!cpu_smt_possible() || (cpu_smt_control == CPU_SMT_DISABLED))) { > + if (boot_cpu_data.x86 < 0x19 && !cpu_smt_possible()) { > setup_force_cpu_cap(X86_FEATURE_SRSO_NO); > return; > } > @@ -2698,8 +2697,12 @@ static ssize_t retbleed_show_state(char *buf) > > static ssize_t srso_show_state(char *buf) > { > - if (boot_cpu_has(X86_FEATURE_SRSO_NO)) > - return sysfs_emit(buf, "Not affected\n"); > + if (boot_cpu_has(X86_FEATURE_SRSO_NO)) { > + if (sched_smt_active()) > + return sysfs_emit(buf, "Not affected\n"); > + else > + return sysfs_emit(buf, "Mitigation: SMT disabled\n"); > + } AFAICT, nowhere in the spec does it say the SRSO_NO bit won't get set by future (fixed) HW. In fact I'd expect it will, similar to other *_NO flags. Regardless, here SRSO_NO seems to mean two different things: "reported safe by host (or HW)" and "not reported safe on Zen1/2 with SMT not possible". Also, in this code, the SRSO_NO+SMT combo doesn't seem logically possible, as srso_show_state() only gets called if X86_BUG_SRSO is set, which only happens if SRSO_NO is not set by the HW/host in the first place. So here, if boot_cpu_has(X86_FEATURE_SRSO_NO), it means SRSO_NO was manually set by srso_select_mitigation(), and SMT can't possibly be enabled. Instead of piggybacking on SRSO_NO, which is confusing, why not just add a new mitigation type, like: diff --git a/arch/x86/kernel/cpu/bugs.c b/arch/x86/kernel/cpu/bugs.c index 6c04aef4b63b..c925b98f5a15 100644 --- a/arch/x86/kernel/cpu/bugs.c +++ b/arch/x86/kernel/cpu/bugs.c @@ -2343,6 +2343,7 @@ early_param("l1tf", l1tf_cmdline); enum srso_mitigation { SRSO_MITIGATION_NONE, SRSO_MITIGATION_MICROCODE, + SRSO_MITIGATION_SMT, SRSO_MITIGATION_SAFE_RET, SRSO_MITIGATION_IBPB, SRSO_MITIGATION_IBPB_ON_VMEXIT, @@ -2359,6 +2360,7 @@ enum srso_mitigation_cmd { static const char * const srso_strings[] = { [SRSO_MITIGATION_NONE] = "Vulnerable", [SRSO_MITIGATION_MICROCODE] = "Mitigation: microcode", + [SRSO_MITIGATION_SMT] = "Mitigation: SMT disabled", [SRSO_MITIGATION_SAFE_RET] = "Mitigation: safe RET", [SRSO_MITIGATION_IBPB] = "Mitigation: IBPB", [SRSO_MITIGATION_IBPB_ON_VMEXIT] = "Mitigation: IBPB on VMEXIT only" @@ -2407,19 +2409,15 @@ static void __init srso_select_mitigation(void) pr_warn("IBPB-extending microcode not applied!\n"); pr_warn(SRSO_NOTICE); } else { - /* - * Enable the synthetic (even if in a real CPUID leaf) - * flags for guests. - */ + /* Enable the synthetic flag, as HW doesn't set it. */ setup_force_cpu_cap(X86_FEATURE_IBPB_BRTYPE); /* * Zen1/2 with SMT off aren't vulnerable after the right * IBPB microcode has been applied. */ - if ((boot_cpu_data.x86 < 0x19) && - (!cpu_smt_possible() || (cpu_smt_control == CPU_SMT_DISABLED))) { - setup_force_cpu_cap(X86_FEATURE_SRSO_NO); + if ((boot_cpu_data.x86 < 0x19) && !cpu_smt_possible()) { + srso_mitigation = SRSO_MITIGATION_SMT; return; } } @@ -2698,9 +2696,6 @@ static ssize_t retbleed_show_state(char *buf) static ssize_t srso_show_state(char *buf) { - if (boot_cpu_has(X86_FEATURE_SRSO_NO)) - return sysfs_emit(buf, "Not affected\n"); - return sysfs_emit(buf, "%s%s\n", srso_strings[srso_mitigation], (cpu_has_ibpb_brtype_microcode() ? "" : ", no microcode"));
On Tue, Aug 15, 2023 at 10:17:53PM +0200, Borislav Petkov wrote: > On Tue, Aug 15, 2023 at 12:58:31PM -0700, Josh Poimboeuf wrote: > > AFAICT, nowhere in the spec does it say the SRSO_NO bit won't get set by > > future (fixed) HW. In fact I'd expect it will, similar to other *_NO > > flags. > > I'm pretty sure it won't. > > SRSO_NO is synthesized by the hypervisor *software*. Nothing else. Citation needed. > It is there so that you don't check microcode version in the guest which > is nearly impossible anyway. > > > Regardless, here SRSO_NO seems to mean two different things: "reported > > safe by host (or HW)" and "not reported safe on Zen1/2 with SMT not > > possible". > > Huh? Can you clarify what doesn't make sense? > > Also, in this code, the SRSO_NO+SMT combo doesn't seem logically > > possible, as srso_show_state() only gets called if X86_BUG_SRSO is set, > > which only happens if SRSO_NO is not set by the HW/host in the first > > place. So here, if boot_cpu_has(X86_FEATURE_SRSO_NO), it means SRSO_NO > > was manually set by srso_select_mitigation(), and SMT can't possibly be > > enabled. > > Have you considered the case where Linux would set SRSO_NO when booting > on future hardware, which is fixed? > > There SRSO_NO and SMT will very much be possible. How is that relevant to my comment? The bug bit still wouldn't get set and srso_show_state() still wouldn't be called.
On Wed, Aug 16, 2023 at 07:35:31PM +0200, Borislav Petkov wrote: > On Wed, Aug 16, 2023 at 09:07:57AM -0700, Josh Poimboeuf wrote: > > In this case srso_show_state() is never called, so the following code > > can't run: > > > > + if (boot_cpu_has(X86_FEATURE_SRSO_NO)) { > > + if (sched_smt_active()) > > + return sysfs_emit(buf, "Not affected\n"); > > Ofc it can. If something has set X86_FEATURE_SRSO_NO early, before the > bug bits detection happens, then you get: > > $ cat /sys/devices/system/cpu/vulnerabilities/spec_rstack_overflow > Not affected No, if the bug bit isn't set then that comes from cpu_show_common(): static ssize_t cpu_show_common(struct device *dev, struct device_attribute *attr, char *buf, unsigned int bug) { if (!boot_cpu_has_bug(bug)) return sysfs_emit(buf, "Not affected\n");
On Wed, Aug 16, 2023 at 11:29:40AM -0700, Josh Poimboeuf wrote: > No, if the bug bit isn't set then that comes from cpu_show_common(): > > static ssize_t cpu_show_common(struct device *dev, struct device_attribute *attr, > char *buf, unsigned int bug) > { > if (!boot_cpu_has_bug(bug)) > return sysfs_emit(buf, "Not affected\n"); Bah, there was that thing too. Ok, I'll zap the sched_smt_active() branch in srso_show_state() then.
On Thu, Aug 17, 2023 at 11:07:27AM +0200, Borislav Petkov wrote: > From: "Borislav Petkov (AMD)" <bp@alien8.de> > Date: Tue, 15 Aug 2023 11:53:13 +0200 > Subject: [PATCH] x86/srso: Correct the mitigation status when SMT is disabled > > Specify how is SRSO mitigated when SMT is disabled. Also, correct the > SMT check for that. > > Fixes: e9fbc47b818b ("x86/srso: Disable the mitigation on unaffected configurations") > Suggested-by: Josh Poimboeuf <jpoimboe@kernel.org> > Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de> > Link: https://lore.kernel.org/r/20230814200813.p5czl47zssuej7nv@treble Acked-by: Josh Poimboeuf <jpoimboe@kernel.org>
diff --git a/arch/x86/kernel/cpu/bugs.c b/arch/x86/kernel/cpu/bugs.c index d02f73c5339d..8959a1b9fb80 100644 --- a/arch/x86/kernel/cpu/bugs.c +++ b/arch/x86/kernel/cpu/bugs.c @@ -2418,8 +2418,10 @@ static void __init srso_select_mitigation(void) * IBPB microcode has been applied. */ if ((boot_cpu_data.x86 < 0x19) && - (!cpu_smt_possible() || (cpu_smt_control == CPU_SMT_DISABLED))) + (!cpu_smt_possible() || (cpu_smt_control == CPU_SMT_DISABLED))) { setup_force_cpu_cap(X86_FEATURE_SRSO_NO); + goto pred_cmd; + } } if (retbleed_mitigation == RETBLEED_MITIGATION_IBPB) { @@ -2696,6 +2698,9 @@ static ssize_t retbleed_show_state(char *buf) static ssize_t srso_show_state(char *buf) { + if (boot_cpu_has(X86_FEATURE_SRSO_NO)) + return sysfs_emit(buf, "Not affected\n"); + return sysfs_emit(buf, "%s%s\n", srso_strings[srso_mitigation], (cpu_has_ibpb_brtype_microcode() ? "" : ", no microcode"));