Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 66CB4C61DA4 for ; Wed, 22 Feb 2023 05:51:02 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230043AbjBVFuP (ORCPT ); Wed, 22 Feb 2023 00:50:15 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:49414 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229561AbjBVFuN (ORCPT ); Wed, 22 Feb 2023 00:50:13 -0500 Received: from dfw.source.kernel.org (dfw.source.kernel.org [IPv6:2604:1380:4641:c500::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 04124311F2 for ; Tue, 21 Feb 2023 21:50:11 -0800 (PST) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id 05C34611EB for ; Wed, 22 Feb 2023 05:50:11 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 66519C4339C for ; Wed, 22 Feb 2023 05:50:10 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1677045010; bh=HyHnRWDCs3dh2VbKsgw8V6XZbBytcbTUxABHJr75Uls=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=IudlILWA6UEqHtp2QHSlbmgqzh3Ed/HHu1V3EAmYvmcdI6HPeRFBWDSkMRu+Rj4AF OsVJn3NhnRN3buzI5rhADnLlxamEvRSRW7oEQtJIGbquaubgvbqdy9Kfwoga/Ofdm+ Aq6faTAF5OXAPacwwM6zCqgnuQj2MNfEjSnz5zr6kVdnGhXwcCXbD42vYKkiwz21Mc PrWCJzQV03wNCxrcux5o8Uw80wsx2DqDN8ndgy9799zPXKmGVowje/TcnMnQxTwR31 Vtbm7Z9fm5ax3B2BgLC5RGbh83GAMCWVr7Xkw0D8CvZ+M05RtUy6r7Z8Pm5P8HbDDu G/HNC9xCVg3ng== Received: by mail-ed1-f41.google.com with SMTP id s26so25897837edw.11 for ; Tue, 21 Feb 2023 21:50:10 -0800 (PST) X-Gm-Message-State: AO0yUKWKSDnPVqhs4HMsma6MPh3aORnrWWR3iC76kZhEj1NkezR4IdA/ AI0BwmR6QwaUGaSedWKn5xcVjmb/ls08g2S2bAx+6w== X-Google-Smtp-Source: AK7set/OX6J6GGDEHEMVX3y1z1pQ3sYoAKb9CmYNSKXJ7b/ygpewKkWEArAfkoV5tSfIjCBcdjzb8XommBcBnljyPHU= X-Received: by 2002:a17:906:bce7:b0:8b1:28f6:8ab3 with SMTP id op7-20020a170906bce700b008b128f68ab3mr7153374ejb.15.1677045008619; Tue, 21 Feb 2023 21:50:08 -0800 (PST) MIME-Version: 1.0 References: <20230221184908.2349578-1-kpsingh@kernel.org> <20230222030728.v4ldlndtnx6gqd6x@desk> In-Reply-To: <20230222030728.v4ldlndtnx6gqd6x@desk> From: KP Singh Date: Tue, 21 Feb 2023 21:49:57 -0800 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH v2 1/2] x86/speculation: Allow enabling STIBP with legacy IBRS To: Pawan Gupta Cc: linux-kernel@vger.kernel.org, pjt@google.com, evn@google.com, jpoimboe@kernel.org, tglx@linutronix.de, x86@kernel.org, hpa@zytor.com, peterz@infradead.org, kim.phillips@amd.com, alexandre.chartre@oracle.com, daniel.sneddon@linux.intel.com, corbet@lwn.net, bp@suse.de, linyujun809@huawei.com, jmattson@google.com, =?UTF-8?Q?Jos=C3=A9_Oliveira?= , Rodrigo Branco , Alexandra Sandulescu , stable@vger.kernel.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Feb 21, 2023 at 7:07 PM Pawan Gupta wrote: > > On Tue, Feb 21, 2023 at 07:49:07PM +0100, KP Singh wrote: > > Setting the IBRS bit implicitly enables STIBP to protect against > > cross-thread branch target injection. With enhanced IBRS, the bit it se= t > > once and is not cleared again. However, on CPUs with just legacy IBRS, > > IBRS bit set on user -> kernel and cleared on kernel -> user (a.k.a > > KERNEL_IBRS). Clearing this bit also disables the implicitly enabled > > STIBP, thus requiring some form of cross-thread protection in userspace= . > > > > Enable STIBP, either opt-in via prctl or seccomp, or always on dependin= g > > on the choice of mitigation selected via spectre_v2_user. > > > > Reported-by: Jos=C3=A9 Oliveira > > Reported-by: Rodrigo Branco > > Reviewed-by: Alexandra Sandulescu > > Fixes: 7c693f54c873 ("x86/speculation: Add spectre_v2=3Dibrs option to = support Kernel IBRS") > > Cc: stable@vger.kernel.org > > Signed-off-by: KP Singh > > --- > > arch/x86/kernel/cpu/bugs.c | 33 ++++++++++++++++++++++----------- > > 1 file changed, 22 insertions(+), 11 deletions(-) > > > > diff --git a/arch/x86/kernel/cpu/bugs.c b/arch/x86/kernel/cpu/bugs.c > > index 85168740f76a..5be6075d8e36 100644 > > --- a/arch/x86/kernel/cpu/bugs.c > > +++ b/arch/x86/kernel/cpu/bugs.c > > @@ -1124,14 +1124,30 @@ spectre_v2_parse_user_cmdline(void) > > return SPECTRE_V2_USER_CMD_AUTO; > > } > > > > -static inline bool spectre_v2_in_ibrs_mode(enum spectre_v2_mitigation = mode) > > +static inline bool spectre_v2_in_eibrs_mode(enum spectre_v2_mitigation= mode) > > { > > - return mode =3D=3D SPECTRE_V2_IBRS || > > - mode =3D=3D SPECTRE_V2_EIBRS || > > + return mode =3D=3D SPECTRE_V2_EIBRS || > > mode =3D=3D SPECTRE_V2_EIBRS_RETPOLINE || > > mode =3D=3D SPECTRE_V2_EIBRS_LFENCE; > > } > > > > +static inline bool spectre_v2_in_ibrs_mode(enum spectre_v2_mitigation = mode) > > +{ > > + return spectre_v2_in_eibrs_mode(mode) || mode =3D=3D SPECTRE_V2_I= BRS; > > +} > > + > > +static inline bool spectre_v2_user_needs_stibp(enum spectre_v2_mitigat= ion mode) > > +{ > > + /* > > + * enhanced IBRS also protects against user-mode attacks as the I= BRS bit > > Maybe: > * Enhanced IBRS mode also protects against cross-thread user-to-= user > * attacks as the IBRS bit updated, thanks! > > > + * remains always set which implicitly enables cross-thread prote= ctions. > > + * However, In legacy IBRS mode, the IBRS bit is set only in kern= el > > + * and cleared on return to userspace. This disables the implicit > > + * cross-thread protections and STIBP is needed. > > + */ > > + return !spectre_v2_in_eibrs_mode(mode); > > +} > > + > > static void __init > > spectre_v2_user_select_mitigation(void) > > { > > @@ -1193,13 +1209,8 @@ spectre_v2_user_select_mitigation(void) > > "always-on" : "conditional"); > > } > > > > - /* > > - * If no STIBP, IBRS or enhanced IBRS is enabled, or SMT impossib= le, > > - * STIBP is not required. > > - */ > > - if (!boot_cpu_has(X86_FEATURE_STIBP) || > > - !smt_possible || > > - spectre_v2_in_ibrs_mode(spectre_v2_enabled)) > > + if (!boot_cpu_has(X86_FEATURE_STIBP) || !smt_possible || > > + !spectre_v2_user_needs_stibp(spectre_v2_enabled)) > > As pointed out in other discussions, it will be great if can get rid of > eIBRS check, and do what the user asked for; or atleast print a warning I think I will keep it as pr_info as, with eIBRS, the user does not really need STIBP and the mitigation is still effective. > about not setting STIBP bit explicitly. That is a bit more complicated as, for now, the user is not really exposed to STIBP explicitly yet. { "auto", SPECTRE_V2_USER_CMD_AUTO, false }, { "off", SPECTRE_V2_USER_CMD_NONE, false }, { "on", SPECTRE_V2_USER_CMD_FORCE, true }, { "prctl", SPECTRE_V2_USER_CMD_PRCTL, false }, { "prctl,ibpb", SPECTRE_V2_USER_CMD_PRCTL_IBPB, false }, { "seccomp", SPECTRE_V2_USER_CMD_SECCOMP, false }, { "seccomp,ibpb", SPECTRE_V2_USER_CMD_SECCOMP_IBPB, false }, I would prefer to do it as a follow up and fix this bug first. It's a bit gnarly and I think we really need to think about the options that are exposed to the user [especially in light of Intel / AMD subtelties]. With the current patch the userspace is still getting working V2 mitigations on both dimensions time (Process A followed by Process B where A does BTI on the subsequent B that are flushed via an IBPB) and space (i.e. cross-thread branch target injection) whenever necessary. > > > return; > > > > /* > > @@ -2327,7 +2338,7 @@ static ssize_t mmio_stale_data_show_state(char *b= uf) > > > > static char *stibp_state(void) > > { > > - if (spectre_v2_in_ibrs_mode(spectre_v2_enabled)) > > + if (!spectre_v2_user_needs_stibp(spectre_v2_enabled)) > > Decoupling STIBP and eIBRS will also get rid of this check. > > > return "";