linux-kernel - Re: [PATCH v9 12/22] KVM: VMX: Virtualize FRED event

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <60C180BF-AD13-48EF-9BA8-CEACF57965EF@zytor.com>
Date: Thu, 29 Jan 2026 09:12:02 -0800
From: Xin Li <xin@...or.com>
To: Chao Gao <chao.gao@...el.com>
Cc: linux-kernel@...r.kernel.org, kvm@...r.kernel.org,
        linux-doc@...r.kernel.org, pbonzini@...hat.com, seanjc@...gle.com,
        corbet@....net, tglx@...utronix.de, mingo@...hat.com, bp@...en8.de,
        dave.hansen@...ux.intel.com, x86@...nel.org, hpa@...or.com,
        luto@...nel.org, peterz@...radead.org, andrew.cooper3@...rix.com,
        hch@...radead.org, sohil.mehta@...el.com
Subject: Re: [PATCH v9 12/22] KVM: VMX: Virtualize FRED event_data


> On Nov 18, 2025, at 7:24 PM, Chao Gao <chao.gao@...el.com> wrote:
> 
>> diff --git a/arch/x86/kvm/vmx/vmx.c b/arch/x86/kvm/vmx/vmx.c
>> index 4a74c9f64f90..0b5d04c863a8 100644
>> --- a/arch/x86/kvm/vmx/vmx.c
>> +++ b/arch/x86/kvm/vmx/vmx.c
>> @@ -1860,6 +1860,9 @@ void vmx_inject_exception(struct kvm_vcpu *vcpu)
>> 
>> vmcs_write32(VM_ENTRY_INTR_INFO_FIELD, intr_info);
>> 
>> + if (is_fred_enabled(vcpu))
>> + vmcs_write64(INJECTED_EVENT_DATA, ex->event_data);
> 
> I think event_data should be reset to 0 in kvm_clear_exception_queue().
> Otherwise, ex->event_data may be stale here, i.e., the event_data from the
> previous event may be injected along with the next event.

It’s no harm to reset it, although it shouldn’t be stale when an event that
uses event data is being injected (otherwise it’s a bug).


> 
>> +
>> vmx_clear_hlt(vcpu);
>> }
>> 
> 
>> /*
>> @@ -950,6 +963,7 @@ void kvm_requeue_exception(struct kvm_vcpu *vcpu, unsigned int nr,
>> vcpu->arch.exception.error_code = error_code;
>> vcpu->arch.exception.has_payload = false;
>> vcpu->arch.exception.payload = 0;
>> + vcpu->arch.exception.event_data = event_data;
> 
> If userspace saves guest events (via kvm_vcpu_ioctl_x86_get_vcpu_events())
> right after an event is requeued, event_data will be lost (as that uAPI only
> saves the payload and KVM doesn't convert the event_data back to a payload
> there). So this event will be delivered with incorrect event_data if the
> event is restored on another system after migration.

Nice catch!

Just to confirm, you are referring to requeueing an original event
via vmx_complete_interrupts(), right?

Regardless of whether FRED or IDT is in use, the event payload is delivered
into the appropriate guest state and then invalidated in
kvm_deliver_exception_payload():

        1) CR2 for #PF

        2) DR6 for #DB

        3) guest_fpu.xfd_err for #NM (in handle_nm_fault_irqoff())

We should be able to recover the FRED event data from there.

Alternatively, we could drop the original event and allow the hardware to
regenerate it upon resuming the guest.  However, this breaks #DB delivery,
as debug exceptions sometimes are triggered post-instruction.


Sean, does it make sense to recover the FRED event data from guest CPU state?