x86/spec-ctrl: Use IST RSB protection for !SVM systems

There is a corner case where a VT-x guest which manages to reliably trigger
non-fatal #MC's could evade the rogue RSB speculation protections that were
supposed to be in place.

This is a lack of defence in depth; Xen does not architecturally execute more
RET than CALL instructions, so an attacker would have to locate a different
gadget (e.g. SpectreRSB) first to execute a transient path of excess RET
instructions.

Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>

diff --git a/xen/arch/x86/spec_ctrl.c b/xen/arch/x86/spec_ctrl.c
index 44e86f3d674dfcb702cf244e0713b36578da2aad..d2cd5459739f7075ac21746a975425fc5894bce2 100644 (file)
--- a/xen/arch/x86/spec_ctrl.c
+++ b/xen/arch/x86/spec_ctrl.c
@@ -1327,8 +1327,24 @@ void __init init_speculation_mitigations(void)
      * mappings.
      */
     if ( opt_rsb_hvm )
+    {
         setup_force_cpu_cap(X86_FEATURE_SC_RSB_HVM);
 
+        /*
+         * For SVM, Xen's RSB safety actions are performed before STGI, so
+         * behave atomically with respect to IST sources.
+         *
+         * For VT-x, NMIs are atomic with VMExit (the NMI gets queued but not
+         * delivered) whereas other IST sources are not atomic.  Specifically,
+         * #MC can hit ahead the RSB safety action in the vmexit path.
+         *
+         * Therefore, it is necessary for the IST logic to protect Xen against
+         * possible rogue RSB speculation.
+         */
+        if ( !cpu_has_svm )
+            default_spec_ctrl_flags |= SCF_ist_rsb;
+    }
+
     ibpb_calculations();
 
     /* Check whether Eager FPU should be enabled by default. */