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] [day] [month] [year] [list]

Message-Id: <A7B34157-A5CA-430C-A459-E8E142951ECB@zytor.com>
Date: Thu, 29 Jan 2026 14:50:51 -0800
From: Xin Li <xin@...or.com>
To: "H. Peter Anvin" <hpa@...or.com>
Cc: Chao Gao <chao.gao@...el.com>, 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 Jan 29, 2026, at 9:21 AM, H. Peter Anvin <hpa@...or.com> wrote:
> 
>> 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.)

Yeah, it's important to keep in mind that DR6 bits are 'sticky'.

Regarding vmx_complete_interrupts(), when a VM migration occurs immediately
following a VM exit with a valid original event saved in the VMCS, we can
safely assume the guest DR6 state remains consistent with the original event
data because there is no chance for guest OS to modify DR6.