From nobody Mon Nov 25 00:28:46 2024 Delivered-To: importer@patchew.org Received-SPF: pass (zohomail.com: domain of lists.xenproject.org designates 192.237.175.120 as permitted sender) client-ip=192.237.175.120; envelope-from=xen-devel-bounces@lists.xenproject.org; helo=lists.xenproject.org; Authentication-Results: mx.zohomail.com; dkim=pass; spf=pass (zohomail.com: domain of lists.xenproject.org designates 192.237.175.120 as permitted sender) smtp.mailfrom=xen-devel-bounces@lists.xenproject.org; dmarc=pass(p=reject dis=none) header.from=citrix.com ARC-Seal: i=1; a=rsa-sha256; t=1718824279; cv=none; d=zohomail.com; s=zohoarc; b=mitcKKNxW7BvehdDpginuhwc3U4d3wGo6QFG6DFU/ZyeqKKDHXILnKfJBRZgWYCORkW+N2wui45ra6dh36krvZAH5V6E41Gdzo+CN4O0OC3LCCva8bSDDlzPCgqdeh7poCtiJQXnzpW62/9Un8igmZwHOkDAY+U6ufJ8R/gMjlw= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; t=1718824279; h=Content-Type:Content-Transfer-Encoding:Cc:Cc:Date:Date:From:From:List-Subscribe:List-Post:List-Id:List-Help:List-Unsubscribe:MIME-Version:Message-ID:Sender:Subject:Subject:To:To:Message-Id:Reply-To; bh=wVqgK+Gsjfrd6Xlaw9wBeTvUFp2FnlECp4adM+DnPBY=; b=kdOyeIj9RlkOuu8BTGl0cPmmIDV3D0tTOO6qYVKwYX5hBeWX6zqYPNLfj4Xp54Zrsd2bE6FYyRU5jzOUOrLc3Ra4vv3tPJCXbAXFHwQ8SZ8gjvqyw2YR6ZxYmm2qLReh8ob61ocdCYX+Kot7+nPbO9R7NQyTGBG/pFVgulFrm/w= ARC-Authentication-Results: i=1; mx.zohomail.com; dkim=pass; spf=pass (zohomail.com: domain of lists.xenproject.org designates 192.237.175.120 as permitted sender) smtp.mailfrom=xen-devel-bounces@lists.xenproject.org; dmarc=pass header.from= (p=reject dis=none) Return-Path: Received: from lists.xenproject.org (lists.xenproject.org [192.237.175.120]) by mx.zohomail.com with SMTPS id 1718824278990252.19551279770815; Wed, 19 Jun 2024 12:11:18 -0700 (PDT) Received: from list by lists.xenproject.org with outflank-mailman.743999.1151009 (Exim 4.92) (envelope-from ) id 1sK0i0-0005nk-9S; Wed, 19 Jun 2024 19:11:04 +0000 Received: by outflank-mailman (output) from mailman id 743999.1151009; Wed, 19 Jun 2024 19:11:04 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1sK0i0-0005nd-6s; Wed, 19 Jun 2024 19:11:04 +0000 Received: by outflank-mailman (input) for mailman id 743999; Wed, 19 Jun 2024 19:11:02 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1sK0hy-0005mQ-CH for xen-devel@lists.xenproject.org; Wed, 19 Jun 2024 19:11:02 +0000 Received: from mail-lf1-x12b.google.com (mail-lf1-x12b.google.com [2a00:1450:4864:20::12b]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id aa128d28-2e6f-11ef-b4bb-af5377834399; Wed, 19 Jun 2024 21:11:00 +0200 (CEST) Received: by mail-lf1-x12b.google.com with SMTP id 2adb3069b0e04-52bc274f438so185839e87.0 for ; Wed, 19 Jun 2024 12:11:00 -0700 (PDT) Received: from andrewcoop.eng.citrite.net ([160.101.139.1]) by smtp.gmail.com with ESMTPSA id a640c23a62f3a-a6f56f99774sm691492166b.203.2024.06.19.12.10.58 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 19 Jun 2024 12:10:58 -0700 (PDT) X-Outflank-Mailman: Message body and most headers restored to incoming version X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: aa128d28-2e6f-11ef-b4bb-af5377834399 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=citrix.com; s=google; t=1718824259; x=1719429059; darn=lists.xenproject.org; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:from:to:cc:subject:date:message-id:reply-to; bh=wVqgK+Gsjfrd6Xlaw9wBeTvUFp2FnlECp4adM+DnPBY=; b=UG+Ty89dX/EOOX3dkYHOpcO8mT85JqPtc/Qca/RiAXiC+5udSlK+S/IH+6Oj+KVHpc cEQ4f8k0TrL3cKqaXWBb3MUZmggwgOlVQauKtt7O87kCiSZHWHAHKBJSzmtN9xAF4/oR GLpxX3hQ+Yw4WQKROw/VjyegN5+dqyj/xTG1I= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1718824259; x=1719429059; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=wVqgK+Gsjfrd6Xlaw9wBeTvUFp2FnlECp4adM+DnPBY=; b=pCTLpVUIlaI7lM3EZMPlMMe/S1IQaqaAFjTMBBsOeiZUNiNj+PVqARqxA/jS5Yv9tw InXKKyndrvULQTEleUgA/UgjVukn7UVt/ag2JIWy/rkPgGGUyiSD4SLvx4HL8aPi7GPW vwQJwSp7WRN+zKgQnhyNTNK+ANX6EbHNHDA3ufUoHJUsUDGXIDLa5c7AX1t8BXQyjbeM 29T8rO46152gyqJ/fpSOs4475L3ln1+mQ3laGH3IYvGDUIgQNP2f9YlSRtkq3wsahuiY snpfb4j40QTqo6lPda98+2apOFCyeSKPk/exKOGivtfFByCc1LPiZOVtME8Kx9xunO5e rzVQ== X-Gm-Message-State: AOJu0Ywt67wYN7bWwjAnAsSobPzcIuJDyJXU3MC1ihJnao2ejSuvLxEo NZAEPx+uGuj5+mvnEBHOJqjlgxgJtcp4wzKNqc+pt8GrjAKoxWHCLa+qfAMOK2xAkE1jtM5XcWp mYfU= X-Google-Smtp-Source: AGHT+IHt18fgs/Ory06X+WGbDJjlVz2q4bgmxXq0/Xj8XMdGvLtWnNxubHbyAdiphZFRsUarEjt1mA== X-Received: by 2002:a05:6512:3f0e:b0:52c:9fd6:1b8a with SMTP id 2adb3069b0e04-52ccaa595c8mr3089490e87.8.1718824258866; Wed, 19 Jun 2024 12:10:58 -0700 (PDT) From: Andrew Cooper To: Xen-devel Cc: Andrew Cooper , Jan Beulich , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , Oleksii Kurochko Subject: [PATCH for-4.19 v2] x86/spec-ctrl: Support for SRSO_US_NO and SRSO_MSR_FIX Date: Wed, 19 Jun 2024 20:10:57 +0100 Message-Id: <20240619191057.2588693-1-andrew.cooper3@citrix.com> X-Mailer: git-send-email 2.39.2 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-ZohoMail-DKIM: pass (identity @citrix.com) X-ZM-MESSAGEID: 1718824280098100001 AMD have updated the SRSO whitepaper[1] with further information. There's a new SRSO_U/S_NO enumeration saying that SRSO attacks can't cross = the user/supervisor boundary. i.e. Xen don't need to use IBPB-on-entry for PV. There's also a new SRSO_MSR_FIX identifying that the BP_SPEC_REDUCE bit is available in MSR_BP_CFG. When set, SRSO attacks can't cross the host/guest boundary. i.e. Xen don't need to use IBPB-on-entry for HVM. Extend ibpb_calculations() to account for these when calculating opt_ibpb_entry_{pv,hvm} defaults. Add a bp-spec-reduce option to control t= he use of BP_SPEC_REDUCE, but activate it by default. Because MSR_BP_CFG is core-scoped with a race condition updating it, repurp= ose amd_check_erratum_1485() into amd_check_bp_cfg() and calculate all updates = at once. Advertise SRSO_U/S_NO to guests whenever possible, as it allows the guest kernel to skip SRSO protections too. This is easy for HVM guests, but hard for PV guests, as both the guest userspace and kernel operate in CPL3. Aft= er discussing with AMD, it is believed to be safe to advertise SRSO_U/S_NO to = PV guests when BP_SPEC_REDUCE is active. Fix a typo in the SRSO_NO's comment. [1] https://www.amd.com/content/dam/amd/en/documents/corporate/cr/speculati= ve-return-stack-overflow-whitepaper.pdf Signed-off-by: Andrew Cooper Reviewed-by: Roger Pau Monn=C3=A9 --- CC: Jan Beulich CC: Roger Pau Monn=C3=A9 CC: Oleksii Kurochko v2: * Add "for HVM guests" to xen-command-line.pandoc * Print details on boot * Don't advertise SRSO_US_NO to PV guests if BP_SPEC_REDUCE isn't active. For 4.19. This should be no functional change on current hardware. On forthcoming hardware, it avoids the substantial perf hits which were necess= ary to protect against the SRSO speculative vulnerability. --- docs/misc/xen-command-line.pandoc | 9 +++- xen/arch/x86/cpu-policy.c | 19 ++++++++ xen/arch/x86/cpu/amd.c | 29 +++++++++--- xen/arch/x86/include/asm/msr-index.h | 1 + xen/arch/x86/include/asm/spec_ctrl.h | 1 + xen/arch/x86/spec_ctrl.c | 49 ++++++++++++++++----- xen/include/public/arch-x86/cpufeatureset.h | 4 +- 7 files changed, 92 insertions(+), 20 deletions(-) diff --git a/docs/misc/xen-command-line.pandoc b/docs/misc/xen-command-line= .pandoc index 1dea7431fab6..88beb64525d5 100644 --- a/docs/misc/xen-command-line.pandoc +++ b/docs/misc/xen-command-line.pandoc @@ -2390,7 +2390,7 @@ By default SSBD will be mitigated at runtime (i.e `ss= bd=3Druntime`). > {ibrs,ibpb,ssbd,psfd, > eager-fpu,l1d-flush,branch-harden,srb-lock, > unpriv-mmio,gds-mit,div-scrub,lock-harden, -> bhi-dis-s}=3D ]` +> bhi-dis-s,bp-spec-reduce}=3D ]` =20 Controls for speculative execution sidechannel mitigations. By default, X= en will pick the most appropriate mitigations based on compiled in support, @@ -2539,6 +2539,13 @@ boolean can be used to force or prevent Xen from usi= ng speculation barriers to protect lock critical regions. This mitigation won't be engaged by defaul= t, and needs to be explicitly enabled on the command line. =20 +On hardware supporting SRSO_MSR_FIX, the `bp-spec-reduce=3D` option can be= used +to force or prevent Xen from using MSR_BP_CFG.BP_SPEC_REDUCE to mitigate t= he +SRSO (Speculative Return Stack Overflow) vulnerability. Xen will use +bp-spec-reduce when available, as it is preferable to using `ibpb-entry=3D= hvm` +to mitigate SRSO for HVM guests, and because it is a necessary prerequisit= e in +order to advertise SRSO_U/S_NO to PV guests. + ### sync_console > `=3D ` =20 diff --git a/xen/arch/x86/cpu-policy.c b/xen/arch/x86/cpu-policy.c index 304dc20cfab8..fd32fe333384 100644 --- a/xen/arch/x86/cpu-policy.c +++ b/xen/arch/x86/cpu-policy.c @@ -14,6 +14,7 @@ #include #include #include +#include #include =20 struct cpu_policy __read_mostly raw_cpu_policy; @@ -605,6 +606,24 @@ static void __init calculate_pv_max_policy(void) __clear_bit(X86_FEATURE_IBRS, fs); } =20 + /* + * SRSO_U/S_NO means that the CPU is not vulnerable to SRSO attacks ac= ross + * the User (CPL3)/Supervisor (CPL<3) boundary. However the PV64 + * user/kernel boundary is CPL3 on both sides, so it won't convey the + * meaning that a PV kernel expects. + * + * PV32 guests are explicitly unsupported WRT speculative safety, so a= re + * ignored to avoid complicating the logic. + * + * After discussions with AMD, it is believed to be safe to offer + * SRSO_US_NO to PV guests when BP_SPEC_REDUCE is active. + * + * If BP_SPEC_REDUCE isn't active, remove SRSO_U/S_NO from the PV max + * policy, which will cause it to filter out of PV default too. + */ + if ( !boot_cpu_has(X86_FEATURE_SRSO_MSR_FIX) || !opt_bp_spec_reduce ) + __clear_bit(X86_FEATURE_SRSO_US_NO, fs); + guest_common_max_feature_adjustments(fs); guest_common_feature_adjustments(fs); =20 diff --git a/xen/arch/x86/cpu/amd.c b/xen/arch/x86/cpu/amd.c index ab92333673b9..5213dfff601d 100644 --- a/xen/arch/x86/cpu/amd.c +++ b/xen/arch/x86/cpu/amd.c @@ -1009,16 +1009,33 @@ static void cf_check fam17_disable_c6(void *arg) wrmsrl(MSR_AMD_CSTATE_CFG, val & mask); } =20 -static void amd_check_erratum_1485(void) +static void amd_check_bp_cfg(void) { - uint64_t val, chickenbit =3D (1 << 5); + uint64_t val, new =3D 0; =20 - if (cpu_has_hypervisor || boot_cpu_data.x86 !=3D 0x19 || !is_zen4_uarch()) + /* + * AMD Erratum #1485. Set bit 5, as instructed. + */ + if (!cpu_has_hypervisor && boot_cpu_data.x86 =3D=3D 0x19 && is_zen4_uarch= ()) + new |=3D (1 << 5); + + /* + * On hardware supporting SRSO_MSR_FIX, activate BP_SPEC_REDUCE by + * default. This lets us do two things: + * + * 1) Avoid IBPB-on-entry to mitigate SRSO attacks from HVM guests. + * 2) Lets us advertise SRSO_US_NO to PV guests. + */ + if (boot_cpu_has(X86_FEATURE_SRSO_MSR_FIX) && opt_bp_spec_reduce) + new |=3D BP_CFG_SPEC_REDUCE; + + /* Avoid reading BP_CFG if we don't intend to change anything. */ + if (!new) return; =20 rdmsrl(MSR_AMD64_BP_CFG, val); =20 - if (val & chickenbit) + if ((val & new) =3D=3D new) return; =20 /* @@ -1027,7 +1044,7 @@ static void amd_check_erratum_1485(void) * same time before the chickenbit is set. It's benign because the * value being written is the same on both. */ - wrmsrl(MSR_AMD64_BP_CFG, val | chickenbit); + wrmsrl(MSR_AMD64_BP_CFG, val | new); } =20 static void cf_check init_amd(struct cpuinfo_x86 *c) @@ -1297,7 +1314,7 @@ static void cf_check init_amd(struct cpuinfo_x86 *c) disable_c1_ramping(); =20 amd_check_zenbleed(); - amd_check_erratum_1485(); + amd_check_bp_cfg(); =20 if (fam17_c6_disabled) fam17_disable_c6(NULL); diff --git a/xen/arch/x86/include/asm/msr-index.h b/xen/arch/x86/include/as= m/msr-index.h index 9cdb5b262566..83fbf4135c6b 100644 --- a/xen/arch/x86/include/asm/msr-index.h +++ b/xen/arch/x86/include/asm/msr-index.h @@ -412,6 +412,7 @@ #define AMD64_DE_CFG_LFENCE_SERIALISE (_AC(1, ULL) << 1) #define MSR_AMD64_EX_CFG 0xc001102cU #define MSR_AMD64_BP_CFG 0xc001102eU +#define BP_CFG_SPEC_REDUCE (_AC(1, ULL) << 4) #define MSR_AMD64_DE_CFG2 0xc00110e3U =20 #define MSR_AMD64_DR0_ADDRESS_MASK 0xc0011027U diff --git a/xen/arch/x86/include/asm/spec_ctrl.h b/xen/arch/x86/include/as= m/spec_ctrl.h index 72347ef2b959..077225418956 100644 --- a/xen/arch/x86/include/asm/spec_ctrl.h +++ b/xen/arch/x86/include/asm/spec_ctrl.h @@ -90,6 +90,7 @@ extern int8_t opt_xpti_hwdom, opt_xpti_domu; =20 extern bool cpu_has_bug_l1tf; extern int8_t opt_pv_l1tf_hwdom, opt_pv_l1tf_domu; +extern bool opt_bp_spec_reduce; =20 /* * The L1D address mask, which might be wider than reported in CPUID, and = the diff --git a/xen/arch/x86/spec_ctrl.c b/xen/arch/x86/spec_ctrl.c index 40f6ae017010..7aabb65ba028 100644 --- a/xen/arch/x86/spec_ctrl.c +++ b/xen/arch/x86/spec_ctrl.c @@ -83,6 +83,7 @@ static bool __initdata opt_unpriv_mmio; static bool __ro_after_init opt_verw_mmio; static int8_t __initdata opt_gds_mit =3D -1; static int8_t __initdata opt_div_scrub =3D -1; +bool __ro_after_init opt_bp_spec_reduce =3D true; =20 static int __init cf_check parse_spec_ctrl(const char *s) { @@ -143,6 +144,7 @@ static int __init cf_check parse_spec_ctrl(const char *= s) opt_unpriv_mmio =3D false; opt_gds_mit =3D 0; opt_div_scrub =3D 0; + opt_bp_spec_reduce =3D false; } else if ( val > 0 ) rc =3D -EINVAL; @@ -363,6 +365,8 @@ static int __init cf_check parse_spec_ctrl(const char *= s) opt_gds_mit =3D val; else if ( (val =3D parse_boolean("div-scrub", s, ss)) >=3D 0 ) opt_div_scrub =3D val; + else if ( (val =3D parse_boolean("bp-spec-reduce", s, ss)) >=3D 0 ) + opt_bp_spec_reduce =3D val; else rc =3D -EINVAL; =20 @@ -505,7 +509,7 @@ static void __init print_details(enum ind_thunk thunk) * Hardware read-only information, stating immunity to certain issues,= or * suggestions of which mitigation to use. */ - printk(" Hardware hints:%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%= s\n", + printk(" Hardware hints:%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%= s%s\n", (caps & ARCH_CAPS_RDCL_NO) ? " RDCL_NO" = : "", (caps & ARCH_CAPS_EIBRS) ? " EIBRS" = : "", (caps & ARCH_CAPS_RSBA) ? " RSBA" = : "", @@ -529,10 +533,11 @@ static void __init print_details(enum ind_thunk thunk) (e8b & cpufeat_mask(X86_FEATURE_BTC_NO)) ? " BTC_NO" = : "", (e8b & cpufeat_mask(X86_FEATURE_IBPB_RET)) ? " IBPB_RET"= : "", (e21a & cpufeat_mask(X86_FEATURE_IBPB_BRTYPE)) ? " IBPB_BRTY= PE" : "", - (e21a & cpufeat_mask(X86_FEATURE_SRSO_NO)) ? " SRSO_NO" = : ""); + (e21a & cpufeat_mask(X86_FEATURE_SRSO_NO)) ? " SRSO_NO" = : "", + (e21a & cpufeat_mask(X86_FEATURE_SRSO_US_NO)) ? " SRSO_US_N= O" : ""); =20 /* Hardware features which need driving to mitigate issues. */ - printk(" Hardware features:%s%s%s%s%s%s%s%s%s%s%s%s%s%s\n", + printk(" Hardware features:%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s\n", (e8b & cpufeat_mask(X86_FEATURE_IBPB)) || (_7d0 & cpufeat_mask(X86_FEATURE_IBRSB)) ? " IBPB" = : "", (e8b & cpufeat_mask(X86_FEATURE_IBRS)) || @@ -551,7 +556,8 @@ static void __init print_details(enum ind_thunk thunk) (caps & ARCH_CAPS_FB_CLEAR_CTRL) ? " FB_CLEAR_= CTRL" : "", (caps & ARCH_CAPS_GDS_CTRL) ? " GDS_CTRL"= : "", (caps & ARCH_CAPS_RFDS_CLEAR) ? " RFDS_CLEA= R" : "", - (e21a & cpufeat_mask(X86_FEATURE_SBPB)) ? " SBPB" = : ""); + (e21a & cpufeat_mask(X86_FEATURE_SBPB)) ? " SBPB" = : "", + (e21a & cpufeat_mask(X86_FEATURE_SRSO_MSR_FIX)) ? " SRSO_MSR_= FIX" : ""); =20 /* Compiled-in support which pertains to mitigations. */ if ( IS_ENABLED(CONFIG_INDIRECT_THUNK) || IS_ENABLED(CONFIG_SHADOW_PAG= ING) || @@ -1120,7 +1126,7 @@ static void __init div_calculations(bool hw_smt_enabl= ed) =20 static void __init ibpb_calculations(void) { - bool def_ibpb_entry =3D false; + bool def_ibpb_entry_pv =3D false, def_ibpb_entry_hvm =3D false; =20 /* Check we have hardware IBPB support before using it... */ if ( !boot_cpu_has(X86_FEATURE_IBRSB) && !boot_cpu_has(X86_FEATURE_IBP= B) ) @@ -1145,22 +1151,41 @@ static void __init ibpb_calculations(void) * Confusion. Mitigate with IBPB-on-entry. */ if ( !boot_cpu_has(X86_FEATURE_BTC_NO) ) - def_ibpb_entry =3D true; + def_ibpb_entry_pv =3D def_ibpb_entry_hvm =3D true; =20 /* - * Further to BTC, Zen3/4 CPUs suffer from Speculative Return Stack - * Overflow in most configurations. Mitigate with IBPB-on-entry i= f we - * have the microcode that makes this an effective option. + * Further to BTC, Zen3 and later CPUs suffer from Speculative Ret= urn + * Stack Overflow in most configurations. Mitigate with IBPB-on-e= ntry + * if we have the microcode that makes this an effective option, + * except where there are other mitigating factors available. */ if ( !boot_cpu_has(X86_FEATURE_SRSO_NO) && boot_cpu_has(X86_FEATURE_IBPB_BRTYPE) ) - def_ibpb_entry =3D true; + { + /* + * SRSO_U/S_NO is a subset of SRSO_NO, identifying that SRSO i= sn't + * possible across the user/supervisor boundary. We only need= to + * use IBPB-on-entry for PV guests on hardware which doesn't + * enumerate SRSO_US_NO. + */ + if ( !boot_cpu_has(X86_FEATURE_SRSO_US_NO) ) + def_ibpb_entry_pv =3D true; + + /* + * SRSO_MSR_FIX enumerates that we can use MSR_BP_CFG.SPEC_RED= UCE + * to mitigate SRSO across the host/guest boundary. We only n= eed + * to use IBPB-on-entry for HVM guests if we haven't enabled t= his + * control. + */ + if ( !boot_cpu_has(X86_FEATURE_SRSO_MSR_FIX) || !opt_bp_spec_r= educe ) + def_ibpb_entry_hvm =3D true; + } } =20 if ( opt_ibpb_entry_pv =3D=3D -1 ) - opt_ibpb_entry_pv =3D IS_ENABLED(CONFIG_PV) && def_ibpb_entry; + opt_ibpb_entry_pv =3D IS_ENABLED(CONFIG_PV) && def_ibpb_entry_pv; if ( opt_ibpb_entry_hvm =3D=3D -1 ) - opt_ibpb_entry_hvm =3D IS_ENABLED(CONFIG_HVM) && def_ibpb_entry; + opt_ibpb_entry_hvm =3D IS_ENABLED(CONFIG_HVM) && def_ibpb_entry_hv= m; =20 if ( opt_ibpb_entry_pv ) { diff --git a/xen/include/public/arch-x86/cpufeatureset.h b/xen/include/publ= ic/arch-x86/cpufeatureset.h index d9eba5e9a714..9c98e4992861 100644 --- a/xen/include/public/arch-x86/cpufeatureset.h +++ b/xen/include/public/arch-x86/cpufeatureset.h @@ -312,7 +312,9 @@ XEN_CPUFEATURE(FSRSC, 11*32+19) /*A Fast = Short REP SCASB */ XEN_CPUFEATURE(AMD_PREFETCHI, 11*32+20) /*A PREFETCHIT{0,1} Instruct= ions */ XEN_CPUFEATURE(SBPB, 11*32+27) /*A Selective Branch Predict= or Barrier */ XEN_CPUFEATURE(IBPB_BRTYPE, 11*32+28) /*A IBPB flushes Branch Type= predictions too */ -XEN_CPUFEATURE(SRSO_NO, 11*32+29) /*A Hardware not vulenrable = to Speculative Return Stack Overflow */ +XEN_CPUFEATURE(SRSO_NO, 11*32+29) /*A Hardware not vulnerable = to Speculative Return Stack Overflow */ +XEN_CPUFEATURE(SRSO_US_NO, 11*32+30) /*A! Hardware not vulnerable = to SRSO across the User/Supervisor boundary */ +XEN_CPUFEATURE(SRSO_MSR_FIX, 11*32+31) /* MSR_BP_CFG.BP_SPEC_REDUC= E available */ =20 /* Intel-defined CPU features, CPUID level 0x00000007:1.ebx, word 12 */ XEN_CPUFEATURE(INTEL_PPIN, 12*32+ 0) /* Protected Processor Inve= ntory Number */ base-commit: 43d5c5d5f70b3f5419e7ef30399d23adf6ddfa8e --=20 2.39.2