Re: [PATCH v5 02/20] KVM: VMX: Save guest EGPRs in VCPU cache

["Chang S. Bae" <chang.seok.bae@intel.com>]

On 7/20/2026 11:20 AM, sashiko-bot@kernel.org wrote:
> 
>>      The register restore path is placed after SPEC_CTRL is restored, so as
>>      to avoid any mis-speculation into EGPR accesses when APX is disabled.
> 
> [Severity: Medium]
> Does the placement in the code match this description?
> 
> Looking at __vmx_vcpu_run() in arch/x86/kvm/vmx/vmenter.S, the EGPR load
> sequence is placed before RESTORE_GUEST_SPEC_CTRL_BODY, which contradicts
> this statement and could expose the host to speculative execution using
> guest EGPR values.

"Register restore" could be imprecise. While the point may stand here 
along with the code change, rewording to "register saving" can help for 
the clarity.

>> +#ifdef CONFIG_KVM_APX
>> +	ALTERNATIVE "jmp .Lload_egprs_done", "", X86_FEATURE_APX
>> +	testl	$KVM_ENTER_EGPR_SWITCH, (%_ASM_SP)
>> +	jz	.Lload_egprs_done
> 
> [Severity: High]
> Does taking this jump create a speculative information leak?
> 
> If the guest disabled APX, we skip loading guest EGPRs but do not clear
> the host's values from the physical registers.
> 
> While the guest architecturally cannot read these registers without
> triggering a #UD, could it execute an APX instruction speculatively before
> the #UD is recognized, potentially exfiltrating sensitive host kernel data?

Today the host kernel does not use APX internally, so there is no host 
EGPR state to leak. If in-kernel APX usage is introduced in the future, 
the point may need to be revisited.

>> +#ifdef CONFIG_KVM_APX
>> +	ALTERNATIVE "jmp .Lclear_egprs_done", "", X86_FEATURE_APX
>> +	test	$KVM_ENTER_EGPR_SWITCH, %_ASM_BX
>> +	jz	.Lclear_egprs_done
> 
> [Severity: High]
> Are guest EGPRs left in physical registers during the VM-Exit speculation
> window?

I think this code still follows the same entry/exit assumptions as the 
existing GPR handling -- clearing after the guest state saved before the 
return.

>> +	/*
>> +	 * Unlike legacy GPRs, saving could be conditional here on VM-Fail,
>> +	 * which however isn't in fastpath. Instead, simply saving EGPRs always.
>> +	 */
>> +	STORE_REGS %_ASM_DI, VMX_vcpu_arch_regs, \
>> +		   %r16, %r17, %r18, %r19, %r20, %r21, %r22, %r23, \
>> +		   %r24, %r25, %r26, %r27, %r28, %r29, %r30, %r31
>> +	CLEAR_REGS %r16d, %r17d, %r18d, %r19d, %r20d, %r21d, %r22d, %r23d, \
>> +		   %r24d, %r25d, %r26d, %r27d, %r28d, %r29d, %r30d, %r31d
> 
> [Severity: Critical]
> Will this cause data corruption of the EGPR state across live migration?
> 
> Because hardware EGPRs are zeroed here, KVM's subsequent host XSAVES in
> fpu_swap_kvm_fpstate() will commit zeroes into the guest's FPU state buffer
> (vcpu->arch.guest_fpu).

No. The VCPU register cache is the authoritative copy of the guest EGPR 
state. Clearing the hardware registers after saving them does not affect 
migration state.

>> @@ -991,6 +991,19 @@ unsigned int __vmx_vcpu_enter_flags(struct vcpu_vmx *vmx)
>>   	    kvm_vcpu_can_access_host_mmio(&vmx->vcpu))
>>   		flags |= KVM_ENTER_CLEAR_CPU_BUFFERS_FOR_MMIO;
>>   
>> +	/*
>> +	 * KVM intercepts XSETBV and thus always tracks the guest XCR0. EGPR
>> +	 * save/restore is gated by this flag. The resulting behavior is:
>> +	 *
>> +	 *  - When the guest enables APX, KVM restores EGPRs (initially zeroed).
>> +	 *  - When the guest disables APX, EGPRs are preserved in the VCPU cache.
>> +	 *  - When APX is re-enabled, the saved state is restored, which matches
>> +	 *    architectural expectations.
>> +	 */
>> +	if (IS_ENABLED(CONFIG_KVM_APX) && cpu_feature_enabled(X86_FEATURE_APX) &&
>> +	    vmx->vcpu.arch.xcr0 & XFEATURE_MASK_APX)
>> +		flags |= KVM_ENTER_EGPR_SWITCH;
>> +
> 
> [Severity: Critical]
> Can an unprivileged guest crash the host by clearing XCR0[APX]?
> 
> Host XCR0 is restored only after executing a significant amount of
> compiler-generated C code. For example, in arch/x86/kvm/x86.c:
> 
> vcpu_enter_guest() {
>      ...
>      exit_fastpath = kvm_x86_call(vcpu_run)(vcpu, run_flags);
>      ...
>      kvm_load_xfeatures(vcpu, false);
>      ...
> }
> 
> If the host kernel is compiled with APX support, the compiler may emit EGPR
> instructions in these generic C exit handlers (like vmx_vcpu_run).

Not with the current kernel build assumptions. Unless the kernel itself 
is compiled with -mapxf (or -march=native on an APX-capable build host 
[*]), the compiler will not emit APX instructions in these paths.

[*] this fix is work-in-progress right now.

Thanks,
Chang