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.

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>

# Commit 4cdb519d797c19ebb8fadc5938cdb47479d5a21b
# Date 2022-07-11 15:21:35 +0100
# Author Andrew Cooper <andrew.cooper3@citrix.com>
# Committer Andrew Cooper <andrew.cooper3@citrix.com>
x86/spec-ctrl: Honour spec-ctrl=0 for unpriv-mmio sub-option

This was an oversight from when unpriv-mmio was introduced.

Fixes: 8c24b70fedcb ("x86/spec-ctrl: Add spec-ctrl=unpriv-mmio")
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>

--- a/docs/misc/xen-command-line.markdown
+++ b/docs/misc/xen-command-line.markdown
@@ -921,7 +921,7 @@ Control bring up of multiple hyper-threa
 ### 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,srb-lock}=<bool> ]`
+>              l1d-flush,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,
@@ -995,8 +995,16 @@ vulnerable to L1TF.
 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>`
--- a/xen/arch/x86/spec_ctrl.c
+++ b/xen/arch/x86/spec_ctrl.c
@@ -59,6 +59,8 @@ static bool_t __initdata cpu_has_bug_mds
 
 static int8_t __initdata opt_srb_lock = -1;
 uint64_t __read_mostly default_xen_mcu_opt_ctrl;
+static bool_t __initdata opt_unpriv_mmio;
+bool_t __read_mostly opt_fb_clear_mmio;
 
 static int __init parse_bti(const char *s)
 {
@@ -129,6 +131,7 @@ static int __init parse_spec_ctrl(char *
             opt_ssbd = 0;
             opt_l1d_flush = 0;
             opt_srb_lock = 0;
+            opt_unpriv_mmio = 0;
         }
         else if ( val > 0 )
             rc = -EINVAL;
@@ -183,6 +186,8 @@ static int __init parse_spec_ctrl(char *
             opt_l1d_flush = 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;
 
@@ -282,7 +287,8 @@ static void __init print_details(enum in
            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"  : "");
 
     /* L1TF diagnostics, printed if vulnerable or PV shadowing is in use. */
     if ( cpu_has_bug_l1tf || opt_pv_l1tf )
@@ -669,7 +675,9 @@ void spec_ctrl_init_domain(struct domain
 {
     bool_t pv = !is_hvm_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 && iommu_enabled);
 }
 
 void __init init_speculation_mitigations(void)
@@ -787,6 +795,24 @@ void __init init_speculation_mitigations
     mds_calculations();
 
     /*
+     * 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 )
+    {
+        uint64_t caps = 0;
+
+        if ( boot_cpu_has(X86_FEATURE_ARCH_CAPS) )
+            rdmsrl(MSR_ARCH_CAPABILITIES, caps);
+        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.
--- a/xen/include/asm-x86/cpufeature.h
+++ b/xen/include/asm-x86/cpufeature.h
@@ -174,6 +174,7 @@
 #define X86_FEATURE_IBRSB	(9*32+26) /* IBRS and IBPB support (used by Intel) */
 #define X86_FEATURE_STIBP	(9*32+27) /* STIBP */
 #define X86_FEATURE_L1D_FLUSH	(9*32+28) /* MSR_FLUSH_CMD and L1D flush. */
+#define X86_FEATURE_ARCH_CAPS   (9*32+29) /* IA32_ARCH_CAPABILITIES MSR */
 #define X86_FEATURE_SSBD	(9*32+31) /* MSR_SPEC_CTRL.SSBD available */
 
 #define cpu_has(c, bit)		test_bit(bit, (c)->x86_capability)
--- a/xen/include/asm-x86/msr-index.h
+++ b/xen/include/asm-x86/msr-index.h
@@ -45,6 +45,7 @@
 #define PRED_CMD_IBPB			(_AC(1, UL) << 0)
 
 #define MSR_ARCH_CAPABILITIES		0x0000010a
+#define ARCH_CAPS_FB_CLEAR		(_AC(1, ULL) << 17)
 
 #define MSR_FLUSH_CMD			0x0000010b
 #define FLUSH_CMD_L1D			(_AC(1, ULL) << 0)
--- a/xen/include/asm-x86/spec_ctrl.h
+++ b/xen/include/asm-x86/spec_ctrl.h
@@ -30,6 +30,7 @@ extern bool_t opt_ibpb;
 extern bool_t opt_ssbd;
 extern bool_t opt_msr_sc_pv, opt_msr_sc_hvm;
 extern int8_t opt_md_clear_pv, opt_md_clear_hvm;
+extern bool_t opt_fb_clear_mmio;
 extern int8_t opt_eager_fpu;
 extern int8_t opt_l1d_flush;
 
@@ -101,7 +102,7 @@ static always_inline void spec_ctrl_ente
      * Note: VERW must be encoded with a memory operand, as it is only that
      * form which causes a flush.
      */
-    if ( opt_md_clear_pv || opt_md_clear_hvm )
+    if ( opt_md_clear_pv || opt_md_clear_hvm || opt_fb_clear_mmio )
         asm volatile ( "verw %[sel]" :: [sel] "m" (info->verw_sel) );
 }
 
