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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <1EA97017-82D2-4C43-B617-D39C68D7BC6F@zytor.com>
Date: Thu, 29 Jan 2026 09:21:02 -0800
From: "H. Peter Anvin" <hpa@...or.com>
To: Xin Li <xin@...or.com>, 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, 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 January 29, 2026 9:12:02 AM PST, Xin Li <xin@...or.com> wrote:
>
>> 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?
>
>
>

I think some bits in DR6 are "sticky", and so unless the guest has explicitly cleared DR6 the event data isn't necessarily derivable from DR6. However, the FRED event data for #DB is directly based on the data already reported by VTx (for exactly the same reason – knowing what the *currently taken* trap represents.)