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.coop...@citrix.com>
---
CC: Jan Beulich <jbeul...@suse.com>
CC: Roger Pau Monné <roger....@citrix.com>
CC: Wei Liu <w...@xen.org>
---
xen/arch/x86/spec_ctrl.c | 16 ++++++++++++++++
1 file changed, 16 insertions(+)
diff --git a/xen/arch/x86/spec_ctrl.c b/xen/arch/x86/spec_ctrl.c
index 44e86f3d674d..d2cd5459739f 100644
--- 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. */
--
2.11.0
