From nobody Thu Apr 10 21:24:35 2025 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 255B11EDA2E; Wed, 2 Apr 2025 18:20:01 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1743618001; cv=none; b=HYmS1ib+FEba+1wSSoG7ngUmFzJOyIm6enJr9ZyT8CWODcx9qRqv/ZEb63OrkfUghPJjllMnx5o3+TqlFdgoOHe01QlJaRmYLRJx48ClU8wyUxXev4xe0qxoz9D8qT6t4ETg1JLEdBWhQcJtv9Xx6UZbVLod9Lg0KQslT58y3g8= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1743618001; c=relaxed/simple; bh=uX8Sj3f5CaYUiWV6uBubNDGp1oMdwdKoROUZtIpOqYM=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=PVWCf76Q80PMqFKTCL1j3rF52uYZS72/FgNTTGnFwV0q6qVQSznasFw6ZGDz98iLBFJSj/5Pa9xzkZvM08+XMRgHw/UcGE5gMPuY2r573jWBCOl2TN7j+OkpxnJxfstSozTm01pnVF1/cAq4jjAYG2KwLQyLf2c7cZ7HCQQe82k= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=mBwC2nUP; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="mBwC2nUP" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 2B365C4CEE5; Wed, 2 Apr 2025 18:20:00 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1743618001; bh=uX8Sj3f5CaYUiWV6uBubNDGp1oMdwdKoROUZtIpOqYM=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=mBwC2nUPCr1WpSagC26/cEajWWbIMW/lHRyvHKsC1i+VZYmy0K3KbEgUBHfq+sCfn pQLVOVJ5752OWOX0/jwN2nQI9sIuxqyCYHyGfPY0rPgE8k6Cdc3IXdK4mKhOyVS0K8 1//L8HmOu7rXSmUkaVfnrDR3kD3C9uWopj13poMNaHQlWiNSlRizFkyn96HFludQlI c4rcc4K7PIqAgFoGh2O/JAq/RMvDYgwvD+HsY5CuQkb7XjxZFwfW+Zcvgdvk4jOxB+ oq8+WHkO/KBZxvNPGMF7SfvvzOXHcx1xQJCExYphHWlWiPqB+eQrAMH7TycaUSa9Lj MAJmKSZxCW6uw== From: Josh Poimboeuf To: x86@kernel.org Cc: linux-kernel@vger.kernel.org, amit@kernel.org, kvm@vger.kernel.org, amit.shah@amd.com, thomas.lendacky@amd.com, bp@alien8.de, tglx@linutronix.de, peterz@infradead.org, pawan.kumar.gupta@linux.intel.com, corbet@lwn.net, mingo@redhat.com, dave.hansen@linux.intel.com, hpa@zytor.com, seanjc@google.com, pbonzini@redhat.com, daniel.sneddon@linux.intel.com, kai.huang@intel.com, sandipan.das@amd.com, boris.ostrovsky@oracle.com, Babu.Moger@amd.com, david.kaplan@amd.com, dwmw@amazon.co.uk, andrew.cooper3@citrix.com Subject: [PATCH v3 5/6] x86/bugs: Don't fill RSB on context switch with eIBRS Date: Wed, 2 Apr 2025 11:19:22 -0700 Message-ID: <8979e2e1d9f48aa4480c2ebd5ea0f9e31f9707e5.1743617897.git.jpoimboe@kernel.org> X-Mailer: git-send-email 2.48.1 In-Reply-To: References: Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" User->user Spectre v2 attacks (including RSB) across context switches are already mitigated by IBPB in cond_mitigation(), if enabled globally or if either the prev or the next task has opted in to protection. RSB filling without IBPB serves no purpose for protecting user space, as indirect branches are still vulnerable. User->kernel RSB attacks are mitigated by eIBRS. In which case the RSB filling on context switch isn't needed, so remove it. Suggested-by: Pawan Gupta Reviewed-by: Pawan Gupta Reviewed-by: Amit Shah Signed-off-by: Josh Poimboeuf Reviewed-by: Nikolay Borisov --- arch/x86/kernel/cpu/bugs.c | 24 ++++++++++++------------ arch/x86/mm/tlb.c | 6 +++--- 2 files changed, 15 insertions(+), 15 deletions(-) diff --git a/arch/x86/kernel/cpu/bugs.c b/arch/x86/kernel/cpu/bugs.c index 354411fd4800..680c779e9711 100644 --- a/arch/x86/kernel/cpu/bugs.c +++ b/arch/x86/kernel/cpu/bugs.c @@ -1591,7 +1591,7 @@ static void __init spec_ctrl_disable_kernel_rrsba(voi= d) rrsba_disabled =3D true; } =20 -static void __init spectre_v2_determine_rsb_fill_type_at_vmexit(enum spect= re_v2_mitigation mode) +static void __init spectre_v2_select_rsb_mitigation(enum spectre_v2_mitiga= tion mode) { /* * Similar to context switches, there are two types of RSB attacks @@ -1615,7 +1615,7 @@ static void __init spectre_v2_determine_rsb_fill_type= _at_vmexit(enum spectre_v2_ */ switch (mode) { case SPECTRE_V2_NONE: - return; + break; =20 case SPECTRE_V2_EIBRS: case SPECTRE_V2_EIBRS_LFENCE: @@ -1624,18 +1624,21 @@ static void __init spectre_v2_determine_rsb_fill_ty= pe_at_vmexit(enum spectre_v2_ pr_info("Spectre v2 / PBRSB-eIBRS: Retire a single CALL on VMEXIT\n"); setup_force_cpu_cap(X86_FEATURE_RSB_VMEXIT_LITE); } - return; + break; =20 case SPECTRE_V2_RETPOLINE: case SPECTRE_V2_LFENCE: case SPECTRE_V2_IBRS: - pr_info("Spectre v2 / SpectreRSB : Filling RSB on VMEXIT\n"); + pr_info("Spectre v2 / SpectreRSB: Filling RSB on context switch and VMEX= IT\n"); + setup_force_cpu_cap(X86_FEATURE_RSB_CTXSW); setup_force_cpu_cap(X86_FEATURE_RSB_VMEXIT); - return; - } + break; =20 - pr_warn_once("Unknown Spectre v2 mode, disabling RSB mitigation at VM exi= t"); - dump_stack(); + default: + pr_warn_once("Unknown Spectre v2 mode, disabling RSB mitigation\n"); + dump_stack(); + break; + } } =20 /* @@ -1867,10 +1870,7 @@ static void __init spectre_v2_select_mitigation(void) * * FIXME: Is this pointless for retbleed-affected AMD? */ - setup_force_cpu_cap(X86_FEATURE_RSB_CTXSW); - pr_info("Spectre v2 / SpectreRSB mitigation: Filling RSB on context switc= h\n"); - - spectre_v2_determine_rsb_fill_type_at_vmexit(mode); + spectre_v2_select_rsb_mitigation(mode); =20 /* * Retpoline protects the kernel, but doesn't protect firmware. IBRS diff --git a/arch/x86/mm/tlb.c b/arch/x86/mm/tlb.c index e459d97ef397..eb83348f9305 100644 --- a/arch/x86/mm/tlb.c +++ b/arch/x86/mm/tlb.c @@ -667,9 +667,9 @@ static void cond_mitigation(struct task_struct *next) prev_mm =3D this_cpu_read(cpu_tlbstate.last_user_mm_spec); =20 /* - * Avoid user/user BTB poisoning by flushing the branch predictor - * when switching between processes. This stops one process from - * doing Spectre-v2 attacks on another. + * Avoid user->user BTB/RSB poisoning by flushing them when switching + * between processes. This stops one process from doing Spectre-v2 + * attacks on another. * * Both, the conditional and the always IBPB mode use the mm * pointer to avoid the IBPB when switching between tasks of the --=20 2.48.1