* Xen Security Advisory 404 v1 (CVE-2022-21123,CVE-2022-21124,CVE-2022-21166) - x86: MMIO Stale Data vulnerabilities
@ 2022-06-14 18:26 Xen.org security team
0 siblings, 0 replies; only message in thread
From: Xen.org security team @ 2022-06-14 18:26 UTC (permalink / raw)
To: xen-announce, xen-devel, xen-users, oss-security; +Cc: Xen.org security team
[-- Attachment #1: Type: text/plain, Size: 4833 bytes --]
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Xen Security Advisory CVE-2022-21123,CVE-2022-21124,CVE-2022-21166 / XSA-404
x86: MMIO Stale Data vulnerabilities
ISSUE DESCRIPTION
=================
This issue is related to the SRBDS, TAA and MDS vulnerabilities. Please
see:
https://xenbits.xen.org/xsa/advisory-320.html (SRBDS)
https://xenbits.xen.org/xsa/advisory-305.html (TAA)
https://xenbits.xen.org/xsa/advisory-297.html (MDS)
Please see Intel's whitepaper:
https://www.intel.com/content/www/us/en/developer/articles/technical/software-security-guidance/technical-documentation/processor-mmio-stale-data-vulnerabilities.html
IMPACT
======
An attacker might be able to directly read or infer data from other
security contexts in the system. This can include data belonging to
other VMs, or to Xen itself. The degree to which an attacker can obtain
data depends on the CPU, and the system configuration.
VULNERABLE SYSTEMS
==================
Systems running all versions of Xen are affected.
Only x86 processors are vulnerable. Processors from other manufacturers
(e.g. ARM) are not believed to be vulnerable.
Only Intel based processors are affected. Processors from other x86
manufacturers (e.g. AMD) are not believed to be vulnerable.
Please consult the Intel Security Advisory for details on the affected
processors and configurations.
Per Xen's support statement, PCI passthrough should be to trusted
domains because the overall system security depends on factors outside
of Xen's control.
As such, Xen, in a supported configuration, is not vulnerable to
DRPW/SBDR.
MITIGATION
==========
All mitigations depend on functionality added in the IPU 2022.1 (May
2022) microcode release from Intel. Consult your dom0 OS vendor.
To the best of the security team's understanding, the summary is as
follows:
Server CPUs (Xeon EP/EX, Scalable, and some Atom servers), excluding
Xeon E3 (which use the client CPU design), are potentially vulnerable to
DRPW (CVE-2022-21166).
Client CPUs (inc Xeon E3) are, furthermore, potentially vulnerable to
SBDR (CVE-2022-21123) and SBDS (CVE-2022-21125).
SBDS only affects CPUs vulnerable to MDS. On these CPUs, there are
previously undiscovered leakage channels. There is no change to the
existing MDS mitigations.
DRPW and SBDR only affects configurations where less privileged domains
have MMIO mappings of buggy endpoints. Consult your hardware vendor.
In configurations where less privileged domains have MMIO access to
buggy endpoints, `spec-ctrl=unpriv-mmio` can be enabled which will cause
Xen to mitigate cross-domain fill buffer leakage, and extend SRBDS
protections to protect RNG data from leakage.
RESOLUTION
==========
Applying the appropriate attached patch resolves this issue.
Note that patches for released versions are generally prepared to
apply to the stable branches, and may not apply cleanly to the most
recent release tarball. Downstreams are encouraged to update to the
tip of the stable branch before applying these patches.
The patches are still under review. An update will be sent once they
are reviewed and the backports are done.
xsa404/xsa404-?.patch xen-unstable
$ sha256sum xsa404*/*
18b307c2cbbd08d568e9dcb2447901d94e22ff1e3945c3436173aa693f6456fb xsa404/xsa404-1.patch
d6f193ad963396285e983aa1c18539f67222582711fc62105c21b71b3b53a97d xsa404/xsa404-2.patch
d2c123ccdf5eb9f862d6e9cb0e59045ae18799a07db149c7d90e301ca20436aa xsa404/xsa404-3.patch
$
NOTE CONCERNING CVE-2022-21127 / Update to SRBDS
================================================
An issue was discovered with the SRBDS microcode mitigation. A
microcode update was released as part of Intel's IPU 2022.1 in May 2022.
Updating microcode is sufficient to fix the issue, with no extra actions
required on Xen's behalf. Consult your dom0 OS vendor or OEM for
updated microcode.
NOTE CONCERNING CVE-2022-21180 / Undefined MMIO Hang
====================================================
A related issue was discovered. See:
https://www.intel.com/content/www/us/en/developer/articles/technical/software-security-guidance/advisory-guidance/undefined-mmio-hang.html
Xen is not vulnerable to UMH in supported configurations.
The only mitigation to is avoid passing impacted devices through to
untrusted guests.
-----BEGIN PGP SIGNATURE-----
iQFABAEBCAAqFiEEI+MiLBRfRHX6gGCng/4UyVfoK9kFAmKo0Z0MHHBncEB4ZW4u
b3JnAAoJEIP+FMlX6CvZc8cH/RFgxQ4L8OewWMxsuowpgLg8NVyYGFMBgttscBh+
ANpjRTnV4yQGpt9nNFDAcXT1c/fvWhypOiwadEtczRl5k/Q96JOKFdiAc1QR35Oj
vmbCLgO20jQ/GdTzaqKUaGBwi8GLShJvH1zMPJ2KuXk5w5uFDhj2gEiB6Kdv9+9O
4FBxQkpDzll0gs5v16ien8btKhEuZj9lNtzXZw5j4+DJD69MvQqsRPVdEt+M17Ox
XGYcpfpLeGUaIUPFTPZDcFIJnMvqPBQyt+2eaeR2ezW2ouNpxepCSPsEDlAmSZ/K
uZA0ShyJD3pfCxjc8eztyF/4zajY5EvuEtWdUZC/3zVaUec=
=4EdA
-----END PGP SIGNATURE-----
[-- Attachment #2: xsa404/xsa404-1.patch --]
[-- Type: application/octet-stream, Size: 9496 bytes --]
From: Andrew Cooper <andrew.cooper3@citrix.com>
Subject: x86/spec-ctrl: Make VERW flushing runtime conditional
Currently, VERW flushing to mitigate MDS is boot time conditional per domain
type. However, to provide mitigations for DRPW (CVE-2022-21166), we need to
conditionally use VERW based on the trustworthiness of the guest, and the
devices passed through.
Remove the PV/HVM alternatives and instead issue a VERW on the return-to-guest
path depending on the SCF_verw bit in cpuinfo spec_ctrl_flags.
Introduce spec_ctrl_init_domain() and d->arch.verw to calculate the VERW
disposition at domain creation time, and context switch the SCF_verw bit.
For now, the existing md-clear= options control VERW flushing in the same way
as before, but later patches will adjust it on a per-domain basis.
No change in behaviour.
This is part of XSA-404.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
diff --git a/docs/misc/xen-command-line.pandoc b/docs/misc/xen-command-line.pandoc
index 0d1d98d715b0..476942a48ba0 100644
--- a/docs/misc/xen-command-line.pandoc
+++ b/docs/misc/xen-command-line.pandoc
@@ -2281,10 +2281,10 @@ in place for guests to use.
Use of a positive boolean value for either of these options is invalid.
-The booleans `pv=`, `hvm=`, `msr-sc=`, `rsb=` and `md-clear=` offer fine
-grained control over the alternative blocks used by Xen. These impact Xen's
-ability to protect itself, and Xen's ability to virtualise support for guests
-to use.
+The booleans `pv=`, `hvm=`, `msr-sc=`, `rsb=` offer fine grained control over
+the alternative blocks used by Xen. (`md-clear=` is no longer an alternative
+block, and just a mitigation setting.) These impact Xen's ability to protect
+itself, and Xen's ability to virtualise support for guests to use.
* `pv=` and `hvm=` offer control over all suboptions for PV and HVM guests
respectively.
diff --git a/xen/arch/x86/domain.c b/xen/arch/x86/domain.c
index a72cc9552ad6..9eddeaa20bd5 100644
--- a/xen/arch/x86/domain.c
+++ b/xen/arch/x86/domain.c
@@ -864,6 +864,8 @@ int arch_domain_create(struct domain *d,
d->arch.msr_relaxed = config->arch.misc_flags & XEN_X86_MSR_RELAXED;
+ spec_ctrl_init_domain(d);
+
return 0;
fail:
@@ -2018,14 +2020,15 @@ static void __context_switch(void)
void context_switch(struct vcpu *prev, struct vcpu *next)
{
unsigned int cpu = smp_processor_id();
+ struct cpu_info *info = get_cpu_info();
const struct domain *prevd = prev->domain, *nextd = next->domain;
unsigned int dirty_cpu = read_atomic(&next->dirty_cpu);
ASSERT(prev != next);
ASSERT(local_irq_is_enabled());
- get_cpu_info()->use_pv_cr3 = false;
- get_cpu_info()->xen_cr3 = 0;
+ info->use_pv_cr3 = false;
+ info->xen_cr3 = 0;
if ( unlikely(dirty_cpu != cpu) && dirty_cpu != VCPU_CPU_CLEAN )
{
@@ -2089,6 +2092,11 @@ void context_switch(struct vcpu *prev, struct vcpu *next)
*last_id = next_id;
}
}
+
+ /* Update the top-of-stack block with the VERW disposition. */
+ info->spec_ctrl_flags &= ~SCF_verw;
+ if ( nextd->arch.verw )
+ info->spec_ctrl_flags |= SCF_verw;
}
sched_context_switched(prev, next);
diff --git a/xen/arch/x86/hvm/vmx/entry.S b/xen/arch/x86/hvm/vmx/entry.S
index 49651f3c435a..5f5de45a1309 100644
--- a/xen/arch/x86/hvm/vmx/entry.S
+++ b/xen/arch/x86/hvm/vmx/entry.S
@@ -87,7 +87,7 @@ UNLIKELY_END(realmode)
/* WARNING! `ret`, `call *`, `jmp *` not safe beyond this point. */
/* SPEC_CTRL_EXIT_TO_VMX Req: %rsp=regs/cpuinfo Clob: */
- ALTERNATIVE "", __stringify(verw CPUINFO_verw_sel(%rsp)), X86_FEATURE_SC_VERW_HVM
+ DO_SPEC_CTRL_COND_VERW
mov VCPU_hvm_guest_cr2(%rbx),%rax
diff --git a/xen/arch/x86/include/asm/cpufeatures.h b/xen/arch/x86/include/asm/cpufeatures.h
index ff3157d52d13..bd45a144ee78 100644
--- a/xen/arch/x86/include/asm/cpufeatures.h
+++ b/xen/arch/x86/include/asm/cpufeatures.h
@@ -35,8 +35,7 @@ XEN_CPUFEATURE(SC_RSB_HVM, X86_SYNTH(19)) /* RSB overwrite needed for HVM
XEN_CPUFEATURE(XEN_SELFSNOOP, X86_SYNTH(20)) /* SELFSNOOP gets used by Xen itself */
XEN_CPUFEATURE(SC_MSR_IDLE, X86_SYNTH(21)) /* (SC_MSR_PV || SC_MSR_HVM) && default_xen_spec_ctrl */
XEN_CPUFEATURE(XEN_LBR, X86_SYNTH(22)) /* Xen uses MSR_DEBUGCTL.LBR */
-XEN_CPUFEATURE(SC_VERW_PV, X86_SYNTH(23)) /* VERW used by Xen for PV */
-XEN_CPUFEATURE(SC_VERW_HVM, X86_SYNTH(24)) /* VERW used by Xen for HVM */
+/* Bits 23,24 unused. */
XEN_CPUFEATURE(SC_VERW_IDLE, X86_SYNTH(25)) /* VERW used by Xen for idle */
XEN_CPUFEATURE(XEN_SHSTK, X86_SYNTH(26)) /* Xen uses CET Shadow Stacks */
XEN_CPUFEATURE(XEN_IBT, X86_SYNTH(27)) /* Xen uses CET Indirect Branch Tracking */
diff --git a/xen/arch/x86/include/asm/domain.h b/xen/arch/x86/include/asm/domain.h
index 3aa0919fa6b8..7ef4cb706dad 100644
--- a/xen/arch/x86/include/asm/domain.h
+++ b/xen/arch/x86/include/asm/domain.h
@@ -319,6 +319,9 @@ struct arch_domain
uint32_t pci_cf8;
uint8_t cmos_idx;
+ /* Use VERW on return-to-guest for its flushing side effect. */
+ bool verw;
+
union {
struct pv_domain pv;
struct hvm_domain hvm;
diff --git a/xen/arch/x86/include/asm/spec_ctrl.h b/xen/arch/x86/include/asm/spec_ctrl.h
index f76029523610..751355f471f4 100644
--- a/xen/arch/x86/include/asm/spec_ctrl.h
+++ b/xen/arch/x86/include/asm/spec_ctrl.h
@@ -24,6 +24,7 @@
#define SCF_use_shadow (1 << 0)
#define SCF_ist_wrmsr (1 << 1)
#define SCF_ist_rsb (1 << 2)
+#define SCF_verw (1 << 3)
#ifndef __ASSEMBLY__
@@ -32,6 +33,7 @@
#include <asm/msr-index.h>
void init_speculation_mitigations(void);
+void spec_ctrl_init_domain(struct domain *d);
extern bool opt_ibpb;
extern bool opt_ssbd;
diff --git a/xen/arch/x86/include/asm/spec_ctrl_asm.h b/xen/arch/x86/include/asm/spec_ctrl_asm.h
index 02b3b18ce69f..6220621797f2 100644
--- a/xen/arch/x86/include/asm/spec_ctrl_asm.h
+++ b/xen/arch/x86/include/asm/spec_ctrl_asm.h
@@ -136,6 +136,18 @@
#endif
.endm
+.macro DO_SPEC_CTRL_COND_VERW
+/*
+ * Requires %rsp=cpuinfo
+ *
+ * Issue a VERW for its flushing side effect if indicated.
+ */
+ testb $SCF_verw, CPUINFO_spec_ctrl_flags(%rsp)
+ jz .L\@_verw_skip
+ verw CPUINFO_verw_sel(%rsp)
+.L\@_verw_skip:
+.endm
+
.macro DO_SPEC_CTRL_ENTRY maybexen:req
/*
* Requires %rsp=regs (also cpuinfo if !maybexen)
@@ -231,8 +243,7 @@
#define SPEC_CTRL_EXIT_TO_PV \
ALTERNATIVE "", \
DO_SPEC_CTRL_EXIT_TO_GUEST, X86_FEATURE_SC_MSR_PV; \
- ALTERNATIVE "", __stringify(verw CPUINFO_verw_sel(%rsp)), \
- X86_FEATURE_SC_VERW_PV
+ DO_SPEC_CTRL_COND_VERW
/*
* Use in IST interrupt/exception context. May interrupt Xen or PV context.
diff --git a/xen/arch/x86/spec_ctrl.c b/xen/arch/x86/spec_ctrl.c
index 1408e4c7abd0..5d50ec7eeeba 100644
--- a/xen/arch/x86/spec_ctrl.c
+++ b/xen/arch/x86/spec_ctrl.c
@@ -36,8 +36,8 @@ static bool __initdata opt_msr_sc_pv = true;
static bool __initdata opt_msr_sc_hvm = true;
static int8_t __initdata opt_rsb_pv = -1;
static bool __initdata opt_rsb_hvm = true;
-static int8_t __initdata opt_md_clear_pv = -1;
-static int8_t __initdata opt_md_clear_hvm = -1;
+static int8_t __ro_after_init opt_md_clear_pv = -1;
+static int8_t __ro_after_init opt_md_clear_hvm = -1;
/* Cmdline controls for Xen's speculative settings. */
static enum ind_thunk {
@@ -933,6 +933,13 @@ static __init void mds_calculations(uint64_t caps)
}
}
+void spec_ctrl_init_domain(struct domain *d)
+{
+ bool pv = is_pv_domain(d);
+
+ d->arch.verw = pv ? opt_md_clear_pv : opt_md_clear_hvm;
+}
+
void __init init_speculation_mitigations(void)
{
enum ind_thunk thunk = THUNK_DEFAULT;
@@ -1197,21 +1204,20 @@ void __init init_speculation_mitigations(void)
boot_cpu_has(X86_FEATURE_MD_CLEAR));
/*
- * Enable MDS defences as applicable. The PV blocks need using all the
- * time, and the Idle blocks need using if either PV or HVM defences are
- * used.
+ * Enable MDS defences as applicable. The Idle blocks need using if
+ * either PV or HVM defences are used.
*
* HVM is more complicated. The MD_CLEAR microcode extends L1D_FLUSH with
* equivelent semantics to avoid needing to perform both flushes on the
- * HVM path. The HVM blocks don't need activating if our hypervisor told
- * us it was handling L1D_FLUSH, or we are using L1D_FLUSH ourselves.
+ * HVM path. Therefore, we don't need VERW in addition to L1D_FLUSH.
+ *
+ * After calculating the appropriate idle setting, simplify
+ * opt_md_clear_hvm to mean just "should we VERW on the way into HVM
+ * guests", so spec_ctrl_init_domain() can calculate suitable settings.
*/
- if ( opt_md_clear_pv )
- setup_force_cpu_cap(X86_FEATURE_SC_VERW_PV);
if ( opt_md_clear_pv || opt_md_clear_hvm )
setup_force_cpu_cap(X86_FEATURE_SC_VERW_IDLE);
- if ( opt_md_clear_hvm && !(caps & ARCH_CAPS_SKIP_L1DFL) && !opt_l1d_flush )
- setup_force_cpu_cap(X86_FEATURE_SC_VERW_HVM);
+ opt_md_clear_hvm &= !(caps & ARCH_CAPS_SKIP_L1DFL) && !opt_l1d_flush;
/*
* Warn the user if they are on MLPDS/MFBDS-vulnerable hardware with HT
[-- Attachment #3: xsa404/xsa404-2.patch --]
[-- Type: application/octet-stream, Size: 5116 bytes --]
From: Andrew Cooper <andrew.cooper3@citrix.com>
Subject: x86/spec-ctrl: Enumeration for MMIO Stale Data controls
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
The three *_NO bits indicate non-susceptibility to the SSDP, FBSDP and PSDP
data movement primitives.
FB_CLEAR indicates that the VERW instruction has re-gained it's Fill Buffer
flushing side effect. This is only enumerated on parts where VERW had
previously lost it's flushing side effect due to the MDS/TAA vulnerabilities
being fixed in hardware.
FB_CLEAR_CTRL is available on a subset of FB_CLEAR parts where the Fill Buffer
clearing side effect of VERW can be turned off for performance reasons.
This is part of XSA-404.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Roger Pau Monné <roger.pau@citrix.com>
diff --git a/xen/arch/x86/include/asm/msr-index.h b/xen/arch/x86/include/asm/msr-index.h
index 6c250bfcadad..ea47f68d0558 100644
--- a/xen/arch/x86/include/asm/msr-index.h
+++ b/xen/arch/x86/include/asm/msr-index.h
@@ -71,6 +71,11 @@
#define ARCH_CAPS_IF_PSCHANGE_MC_NO (_AC(1, ULL) << 6)
#define ARCH_CAPS_TSX_CTRL (_AC(1, ULL) << 7)
#define ARCH_CAPS_TAA_NO (_AC(1, ULL) << 8)
+#define ARCH_CAPS_SBDR_SSDP_NO (_AC(1, ULL) << 13)
+#define ARCH_CAPS_FBSDP_NO (_AC(1, ULL) << 14)
+#define ARCH_CAPS_PSDP_NO (_AC(1, ULL) << 15)
+#define ARCH_CAPS_FB_CLEAR (_AC(1, ULL) << 17)
+#define ARCH_CAPS_FB_CLEAR_CTRL (_AC(1, ULL) << 18)
#define ARCH_CAPS_RRSBA (_AC(1, ULL) << 19)
#define ARCH_CAPS_BHI_NO (_AC(1, ULL) << 20)
@@ -90,6 +95,7 @@
#define MCU_OPT_CTRL_RNGDS_MITG_DIS (_AC(1, ULL) << 0)
#define MCU_OPT_CTRL_RTM_ALLOW (_AC(1, ULL) << 1)
#define MCU_OPT_CTRL_RTM_LOCKED (_AC(1, ULL) << 2)
+#define MCU_OPT_CTRL_FB_CLEAR_DIS (_AC(1, ULL) << 3)
#define MSR_RTIT_OUTPUT_BASE 0x00000560
#define MSR_RTIT_OUTPUT_MASK 0x00000561
diff --git a/xen/arch/x86/spec_ctrl.c b/xen/arch/x86/spec_ctrl.c
index 5d50ec7eeeba..ded33f5d0f2e 100644
--- a/xen/arch/x86/spec_ctrl.c
+++ b/xen/arch/x86/spec_ctrl.c
@@ -323,7 +323,7 @@ static void __init print_details(enum ind_thunk thunk, uint64_t caps)
* 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\n",
+ printk(" Hardware hints:%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_IBRS_ALL) ? " IBRS_ALL" : "",
(caps & ARCH_CAPS_RSBA) ? " RSBA" : "",
@@ -332,13 +332,16 @@ static void __init print_details(enum ind_thunk thunk, uint64_t caps)
(caps & ARCH_CAPS_SSB_NO) ? " SSB_NO" : "",
(caps & ARCH_CAPS_MDS_NO) ? " MDS_NO" : "",
(caps & ARCH_CAPS_TAA_NO) ? " TAA_NO" : "",
+ (caps & ARCH_CAPS_SBDR_SSDP_NO) ? " SBDR_SSDP_NO" : "",
+ (caps & ARCH_CAPS_FBSDP_NO) ? " FBSDP_NO" : "",
+ (caps & ARCH_CAPS_PSDP_NO) ? " PSDP_NO" : "",
(e8b & cpufeat_mask(X86_FEATURE_IBRS_ALWAYS)) ? " IBRS_ALWAYS" : "",
(e8b & cpufeat_mask(X86_FEATURE_STIBP_ALWAYS)) ? " STIBP_ALWAYS" : "",
(e8b & cpufeat_mask(X86_FEATURE_IBRS_FAST)) ? " IBRS_FAST" : "",
(e8b & cpufeat_mask(X86_FEATURE_IBRS_SAME_MODE)) ? " IBRS_SAME_MODE" : "");
/* Hardware features which need driving to mitigate issues. */
- printk(" Hardware features:%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\n",
(e8b & cpufeat_mask(X86_FEATURE_IBPB)) ||
(_7d0 & cpufeat_mask(X86_FEATURE_IBRSB)) ? " IBPB" : "",
(e8b & cpufeat_mask(X86_FEATURE_IBRS)) ||
@@ -353,7 +356,9 @@ static void __init print_details(enum ind_thunk thunk, uint64_t caps)
(_7d0 & cpufeat_mask(X86_FEATURE_MD_CLEAR)) ? " MD_CLEAR" : "",
(_7d0 & cpufeat_mask(X86_FEATURE_SRBDS_CTRL)) ? " SRBDS_CTRL" : "",
(e8b & cpufeat_mask(X86_FEATURE_VIRT_SSBD)) ? " VIRT_SSBD" : "",
- (caps & ARCH_CAPS_TSX_CTRL) ? " TSX_CTRL" : "");
+ (caps & ARCH_CAPS_TSX_CTRL) ? " TSX_CTRL" : "",
+ (caps & ARCH_CAPS_FB_CLEAR) ? " FB_CLEAR" : "",
+ (caps & ARCH_CAPS_FB_CLEAR_CTRL) ? " FB_CLEAR_CTRL" : "");
/* Compiled-in support which pertains to mitigations. */
if ( IS_ENABLED(CONFIG_INDIRECT_THUNK) || IS_ENABLED(CONFIG_SHADOW_PAGING) )
[-- Attachment #4: xsa404/xsa404-3.patch --]
[-- Type: application/octet-stream, Size: 8009 bytes --]
From: Andrew Cooper <andrew.cooper3@citrix.com>
Subject: x86/spec-ctrl: Add spec-ctrl=unpriv-mmio
Per Xen's support statement, PCI passthrough should be to trusted domains
because the overall system security depends on factors outside of Xen's
control.
As such, Xen, in a supported configuration, is not vulnerable to DRPW/SBDR.
However, users who have risk assessed their configuration may be happy with
the risk of DoS, but unhappy with the risk of cross-domain data leakage. Such
users should enable this option.
When enabled, and when running with on impacted systems with the Intel May
2022 microcode, this option mitigates cross-domain fill buffer leakage by
flushing on entry to any domain with MMIO access, and engages the existing
srb-lock to protect RNG data.
This is part of XSA-404.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
diff --git a/docs/misc/xen-command-line.pandoc b/docs/misc/xen-command-line.pandoc
index 476942a48ba0..adfd4ad39941 100644
--- a/docs/misc/xen-command-line.pandoc
+++ b/docs/misc/xen-command-line.pandoc
@@ -2259,7 +2259,7 @@ By default SSBD will be mitigated at runtime (i.e `ssbd=runtime`).
### spec-ctrl (x86)
> `= List of [ <bool>, xen=<bool>, {pv,hvm,msr-sc,rsb,md-clear}=<bool>,
> bti-thunk=retpoline|lfence|jmp, {ibrs,ibpb,ssbd,eager-fpu,
-> l1d-flush,branch-harden,srb-lock}=<bool> ]`
+> l1d-flush,branch-harden,srb-lock,unpriv-mmio}=<bool> ]`
Controls for speculative execution sidechannel mitigations. By default, Xen
will pick the most appropriate mitigations based on compiled in support,
@@ -2339,8 +2339,18 @@ Xen will enable this mitigation.
On hardware supporting SRBDS_CTRL, the `srb-lock=` option can be used to force
or prevent Xen from protect the Special Register Buffer from leaking stale
data. By default, Xen will enable this mitigation, except on parts where MDS
-is fixed and TAA is fixed/mitigated (in which case, there is believed to be no
-way for an attacker to obtain the stale data).
+is fixed and TAA is fixed/mitigated and there are no unprivileged MMIO
+mappings (in which case, there is believed to be no way for an attacker to
+obtain stale data).
+
+The `unpriv-mmio=` boolean indicates whether the system has (or will have)
+less than fully privileged domains with access to MMIO devices. Per Xen's
+support statement PCI Passthrough should be to trusted guests only, but users
+who have risk-assessed further might be happy to tolerate the risk of DoS, but
+not of data leakage. Such user should enable this option. When enabled, this
+option uses `FB_CLEAR` and/or `SRBDS_CTRL` functionality available in the
+Intel May 2022 microcode release to mitigate cross-domain leakage of fill
+buffers via the MMIO Stale Data vulnerabilities.
### sync_console
> `= <boolean>`
diff --git a/xen/arch/x86/spec_ctrl.c b/xen/arch/x86/spec_ctrl.c
index ded33f5d0f2e..c19e82e07143 100644
--- a/xen/arch/x86/spec_ctrl.c
+++ b/xen/arch/x86/spec_ctrl.c
@@ -67,6 +67,8 @@ static bool __initdata cpu_has_bug_msbds_only; /* => minimal HT impact. */
static bool __initdata cpu_has_bug_mds; /* Any other M{LP,SB,FB}DS combination. */
static int8_t __initdata opt_srb_lock = -1;
+static bool __ro_after_init opt_unpriv_mmio;
+static bool __ro_after_init opt_fb_clear_mmio;
static int __init cf_check parse_spec_ctrl(const char *s)
{
@@ -184,6 +186,8 @@ static int __init cf_check parse_spec_ctrl(const char *s)
opt_branch_harden = val;
else if ( (val = parse_boolean("srb-lock", s, ss)) >= 0 )
opt_srb_lock = val;
+ else if ( (val = parse_boolean("unpriv-mmio", s, ss)) >= 0 )
+ opt_unpriv_mmio = val;
else
rc = -EINVAL;
@@ -392,7 +396,8 @@ static void __init print_details(enum ind_thunk thunk, uint64_t caps)
opt_srb_lock ? " SRB_LOCK+" : " SRB_LOCK-",
opt_ibpb ? " IBPB" : "",
opt_l1d_flush ? " L1D_FLUSH" : "",
- opt_md_clear_pv || opt_md_clear_hvm ? " VERW" : "",
+ opt_md_clear_pv || opt_md_clear_hvm ||
+ opt_fb_clear_mmio ? " VERW" : "",
opt_branch_harden ? " BRANCH_HARDEN" : "");
/* L1TF diagnostics, printed if vulnerable or PV shadowing is in use. */
@@ -942,7 +947,9 @@ void spec_ctrl_init_domain(struct domain *d)
{
bool pv = is_pv_domain(d);
- d->arch.verw = pv ? opt_md_clear_pv : opt_md_clear_hvm;
+ d->arch.verw =
+ (pv ? opt_md_clear_pv : opt_md_clear_hvm) ||
+ (opt_fb_clear_mmio && is_iommu_enabled(d));
}
void __init init_speculation_mitigations(void)
@@ -1197,6 +1204,18 @@ void __init init_speculation_mitigations(void)
mds_calculations(caps);
/*
+ * Parts which enumerate FB_CLEAR are those which have reintroduced the
+ * VERW flushing side because of a suceptability to FBSDP.
+ *
+ * If unprivileged guests have (or will have) MMIO mappings, we can
+ * mitigate cross-domain leakage of fill buffer data by issuing VERW on
+ * the return-to-guest path. All privileges of software responsible for
+ * not leaking their own secrets when using MMIO.
+ */
+ if ( opt_unpriv_mmio )
+ opt_fb_clear_mmio = caps & ARCH_CAPS_FB_CLEAR;
+
+ /*
* By default, enable PV and HVM mitigations on MDS-vulnerable hardware.
* This will only be a token effort for MLPDS/MFBDS when HT is enabled,
* but it is somewhat better than nothing.
@@ -1209,8 +1228,8 @@ void __init init_speculation_mitigations(void)
boot_cpu_has(X86_FEATURE_MD_CLEAR));
/*
- * Enable MDS defences as applicable. The Idle blocks need using if
- * either PV or HVM defences are used.
+ * Enable MDS/MMIO defences as applicable. The Idle blocks need using if
+ * either PV or HVM, or if we give MMIO access to untrusted guests.
*
* HVM is more complicated. The MD_CLEAR microcode extends L1D_FLUSH with
* equivelent semantics to avoid needing to perform both flushes on the
@@ -1220,7 +1239,7 @@ void __init init_speculation_mitigations(void)
* opt_md_clear_hvm to mean just "should we VERW on the way into HVM
* guests", so spec_ctrl_init_domain() can calculate suitable settings.
*/
- if ( opt_md_clear_pv || opt_md_clear_hvm )
+ if ( opt_md_clear_pv || opt_md_clear_hvm || opt_fb_clear_mmio )
setup_force_cpu_cap(X86_FEATURE_SC_VERW_IDLE);
opt_md_clear_hvm &= !(caps & ARCH_CAPS_SKIP_L1DFL) && !opt_l1d_flush;
@@ -1285,14 +1304,19 @@ void __init init_speculation_mitigations(void)
* On some SRBDS-affected hardware, it may be safe to relax srb-lock by
* default.
*
- * On parts which enumerate MDS_NO and not TAA_NO, TSX is the only known
- * way to access the Fill Buffer. If TSX isn't available (inc. SKU
- * reasons on some models), or TSX is explicitly disabled, then there is
- * no need for the extra overhead to protect RDRAND/RDSEED.
+ * All parts with SRBDS_CTRL suffer SSDP, the mechanism by which stale RNG
+ * data becomes available to other contexts. To recover the data, an
+ * attaker needs to use:
+ * - SBDS (MDS or TAA to sample the cores fill buffer)
+ * - SBDR (Architectrually retrieve stale transaction buffer contents)
+ * - DRPW (Architectrually latch stale fill buffer data)
+ *
+ * Therefore, on MDS_NO parts, and TAA_NO or TSX unavailable/disabled, and
+ * no unprivileged MMIO access, the RNG data doesn't need protecting.
*/
if ( cpu_has_srbds_ctrl )
{
- if ( opt_srb_lock == -1 &&
+ if ( opt_srb_lock == -1 && !opt_unpriv_mmio &&
(caps & (ARCH_CAPS_MDS_NO|ARCH_CAPS_TAA_NO)) == ARCH_CAPS_MDS_NO &&
(!cpu_has_hle || ((caps & ARCH_CAPS_TSX_CTRL) && rtm_disabled)) )
opt_srb_lock = 0;
^ permalink raw reply related [flat|nested] only message in thread
only message in thread, other threads:[~2022-06-14 18:27 UTC | newest]
Thread overview: (only message) (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2022-06-14 18:26 Xen Security Advisory 404 v1 (CVE-2022-21123,CVE-2022-21124,CVE-2022-21166) - x86: MMIO Stale Data vulnerabilities Xen.org security team
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.