linux-kernel - Re: [PATCH v3] KVM: x86: Add x2APIC "features" to control EOI broadcast suppression

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: <30d15b0b01a72f592c218bdc6fec6f3aad5212f0.camel@intel.com>
Date: Tue, 25 Nov 2025 21:16:54 +0000
From: "Huang, Kai" <kai.huang@...el.com>
To: "pbonzini@...hat.com" <pbonzini@...hat.com>, "khushit.shah@...anix.com"
	<khushit.shah@...anix.com>, "seanjc@...gle.com" <seanjc@...gle.com>
CC: "x86@...nel.org" <x86@...nel.org>, "bp@...en8.de" <bp@...en8.de>,
	"hpa@...or.com" <hpa@...or.com>, "mingo@...hat.com" <mingo@...hat.com>,
	"tglx@...utronix.de" <tglx@...utronix.de>, "dave.hansen@...ux.intel.com"
	<dave.hansen@...ux.intel.com>, "kvm@...r.kernel.org" <kvm@...r.kernel.org>,
	"shaju.abraham@...anix.com" <shaju.abraham@...anix.com>, "Kohler, Jon"
	<jon@...anix.com>, "linux-kernel@...r.kernel.org"
	<linux-kernel@...r.kernel.org>, "stable@...r.kernel.org"
	<stable@...r.kernel.org>
Subject: Re: [PATCH v3] KVM: x86: Add x2APIC "features" to control EOI
 broadcast suppression

On Tue, 2025-11-25 at 18:05 +0000, Khushit Shah wrote:
> Add two flags for KVM_CAP_X2APIC_API to allow userspace to control support
> for Suppress EOI Broadcasts, which KVM completely mishandles.  When x2APIC
> support was first added, KVM incorrectly advertised and "enabled" Suppress
> EOI Broadcast, without fully supporting the I/O APIC side of the equation,
> i.e. without adding directed EOI to KVM's in-kernel I/O APIC.
> 
> That flaw was carried over to split IRQCHIP support, i.e. KVM advertised
> support for Suppress EOI Broadcasts irrespective of whether or not the
> userspace I/O APIC implementation supported directed EOIs.  Even worse,
> KVM didn't actually suppress EOI broadcasts, i.e. userspace VMMs without
> support for directed EOI came to rely on the "spurious" broadcasts.
> 
> KVM "fixed" the in-kernel I/O APIC implementation by completely disabling
> support for Suppress EOI Broadcasts in commit 0bcc3fb95b97 ("KVM: lapic:
> stop advertising DIRECTED_EOI when in-kernel IOAPIC is in use"), but
> didn't do anything to remedy userspace I/O APIC implementations.
> 
> KVM's bogus handling of Suppress EOI Broadcast is problematic when the guest
> relies on interrupts being masked in the I/O APIC until well after the
> initial local APIC EOI.  E.g. Windows with Credential Guard enabled
> handles interrupts in the following order:
>   1. Interrupt for L2 arrives.
>   2. L1 APIC EOIs the interrupt.
>   3. L1 resumes L2 and injects the interrupt.
>   4. L2 EOIs after servicing.
>   5. L1 performs the I/O APIC EOI.
> 
> Because KVM EOIs the I/O APIC at step #2, the guest can get an interrupt
> storm, e.g. if the IRQ line is still asserted and userspace reacts to the
> EOI by re-injecting the IRQ, because the guest doesn't de-assert the line
> until step #4, and doesn't expect the interrupt to be re-enabled until
> step #5.
> 
> Unfortunately, simply "fixing" the bug isn't an option, as KVM has no way
> of knowing if the userspace I/O APIC supports directed EOIs, i.e.
> suppressing EOI broadcasts would result in interrupts being stuck masked
> in the userspace I/O APIC due to step #5 being ignored by userspace.  And
> fully disabling support for Suppress EOI Broadcast is also undesirable, as
> picking up the fix would require a guest reboot, *and* more importantly
> would change the virtual CPU model exposed to the guest without any buy-in
> from userspace.
> 
> Add two flags to allow userspace to choose exactly how to solve the
> immediate issue, and in the long term to allow userspace to control the
> virtual CPU model that is exposed to the guest (KVM should never have
> enabled support for Suppress EOI Broadcast without a userspace opt-in).
> 
> Note, Suppress EOI Broadcasts is defined only in Intel's SDM, not in AMD's
> APM.  But the bit is writable on some AMD CPUs, e.g. Turin, and KVM's ABI
> is to support Directed EOI (KVM's name) irrespective of guest CPU vendor.
> 
> Fixes: 7543a635aa09 ("KVM: x86: Add KVM exit for IOAPIC EOIs")
> Closes: https://lore.kernel.org/kvm/7D497EF1-607D-4D37-98E7-DAF95F099342@nutanix.com
> Cc: stable@...r.kernel.org
> Co-developed-by: Sean Christopherson <seanjc@...gle.com>
> Signed-off-by: Sean Christopherson <seanjc@...gle.com>
> Signed-off-by: Khushit Shah <khushit.shah@...anix.com>

Reviewed-by: Kai Huang <kai.huang@...el.com>