1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
|
From 2e82446cb252f6c8ac697e81f4155872c69afde4 Mon Sep 17 00:00:00 2001
From: Andrew Cooper <andrew.cooper3@citrix.com>
Date: Mon, 13 Jun 2022 19:18:32 +0100
Subject: [PATCH 32/51] x86/spec-ctrl: Add spec-ctrl=unpriv-mmio
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
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.
On CPUs vulnerable to MDS, the existing mitigations are the best we can do to
mitigate MMIO cross-domain data leakage.
On CPUs fixed to MDS but vulnerable MMIO stale data leakage, this option:
* On CPUs susceptible to FBSDP, mitigates cross-domain fill buffer leakage
using FB_CLEAR.
* On CPUs susceptible to SBDR, mitigates RNG data recovery by engaging the
srb-lock, previously used to mitigate SRBDS.
Both mitigations require microcode from IPU 2022.1, May 2022.
This is part of XSA-404.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Roger Pau Monné <roger.pau@citrix.com>
(cherry picked from commit 8c24b70fedcb52633b2370f834d8a2be3f7fa38e)
---
docs/misc/xen-command-line.pandoc | 14 +++++++--
xen/arch/x86/spec_ctrl.c | 48 ++++++++++++++++++++++++-------
2 files changed, 48 insertions(+), 14 deletions(-)
diff --git a/docs/misc/xen-command-line.pandoc b/docs/misc/xen-command-line.pandoc
index d5cb09f86541..a642e43476a2 100644
--- a/docs/misc/xen-command-line.pandoc
+++ b/docs/misc/xen-command-line.pandoc
@@ -2235,7 +2235,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,
@@ -2314,8 +2314,16 @@ 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 granted access to MMIO devices. By
+default, this option is disabled. If enabled, Xen will use the `FB_CLEAR`
+and/or `SRBDS_CTRL` functionality available in the Intel May 2022 microcode
+release to mitigate cross-domain leakage of data 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 d285538bde9f..099113ba41e6 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 __initdata opt_unpriv_mmio;
+static bool __read_mostly opt_fb_clear_mmio;
static int __init parse_spec_ctrl(const char *s)
{
@@ -184,6 +186,8 @@ static int __init 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. */
@@ -941,7 +946,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)
@@ -1195,6 +1202,18 @@ void __init init_speculation_mitigations(void)
mds_calculations(caps);
+ /*
+ * Parts which enumerate FB_CLEAR are those which are post-MDS_NO and have
+ * reintroduced the VERW fill buffer flushing side effect because of a
+ * susceptibility 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.
+ */
+ 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,
@@ -1208,18 +1227,20 @@ 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 the PV or HVM MDS defences are used, or if we may give MMIO
+ * access to untrusted guests.
*
* HVM is more complicated. The MD_CLEAR microcode extends L1D_FLUSH with
* equivalent semantics to avoid needing to perform both flushes on the
- * HVM path. Therefore, we don't need VERW in addition to L1D_FLUSH.
+ * HVM path. Therefore, we don't need VERW in addition to L1D_FLUSH (for
+ * MDS mitigations. L1D_FLUSH is not safe for MMIO mitigations.)
*
* 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 || 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;
@@ -1284,14 +1305,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
+ * attacker needs to use:
+ * - SBDS (MDS or TAA to sample the cores fill buffer)
+ * - SBDR (Architecturally retrieve stale transaction buffer contents)
+ * - DRPW (Architecturally latch stale fill buffer data)
+ *
+ * On MDS_NO parts, and with TAA_NO or TSX unavailable/disabled, and there
+ * is 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;
--
2.35.1
|
GitWeb