From: Andrew Cooper Subject: x86/spec-ctrl: Defer CR4_PV32_RESTORE on the cstar_enter path As stated (correctly) by the comment next to SPEC_CTRL_ENTRY_FROM_PV, between the two hunks visible in the patch, RET's are not safe prior to this point. CR4_PV32_RESTORE hides a CALL/RET pair in certain configurations (PV32 compiled in, SMEP or SMAP active), and the RET can be attacked with one of several known speculative issues. Furthermore, CR4_PV32_RESTORE also hides a reference to the cr4_pv32_mask global variable, which is not safe when XPTI is active before restoring Xen's full pagetables. This crash has gone unnoticed because it is only AMD CPUs which permit the SYSCALL instruction in compatibility mode, and these are not vulnerable to Meltdown so don't activate XPTI by default. This is XSA-429 / CVE-2022-42331 Fixes: 5e7962901131 ("x86/entry: Organise the use of MSR_SPEC_CTRL at each entry/exit point") Fixes: 5784de3e2067 ("x86: Meltdown band-aid against malicious 64-bit PV guests") Signed-off-by: Andrew Cooper Reviewed-by: Jan Beulich diff --git a/xen/arch/x86/x86_64/entry.S b/xen/arch/x86/x86_64/entry.S index ae012851819a..7675a59ff057 100644 --- a/xen/arch/x86/x86_64/entry.S +++ b/xen/arch/x86/x86_64/entry.S @@ -288,7 +288,6 @@ ENTRY(cstar_enter) ALTERNATIVE "", "setssbsy", X86_FEATURE_XEN_SHSTK #endif push %rax /* Guest %rsp */ - CR4_PV32_RESTORE movq 8(%rsp), %rax /* Restore guest %rax. */ movq $FLAT_USER_SS32, 8(%rsp) /* Assume a 64bit domain. Compat handled lower. */ pushq %r11 @@ -312,6 +311,8 @@ ENTRY(cstar_enter) .Lcstar_cr3_okay: sti + CR4_PV32_RESTORE + movq STACK_CPUINFO_FIELD(current_vcpu)(%rbx), %rbx #ifdef CONFIG_PV32