linux-kernel - Re: [PATCH] KVM: x86: skip userspace IOAPIC EOI exit when Directed EOI is enabled

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: <aQjd1q5jF5uSTfmu@google.com>
Date: Mon, 3 Nov 2025 08:57:51 -0800
From: Sean Christopherson <seanjc@...gle.com>
To: Khushit Shah <khushit.shah@...anix.com>
Cc: Jon Kohler <jon@...anix.com>, Paolo Bonzini <pbonzini@...hat.com>, 
	Thomas Gleixner <tglx@...utronix.de>, Ingo Molnar <mingo@...hat.com>, Borislav Petkov <bp@...en8.de>, 
	Dave Hansen <dave.hansen@...ux.intel.com>, "x86@...nel.org" <x86@...nel.org>, 
	"H. Peter Anvin" <hpa@...or.com>, "kvm@...r.kernel.org" <kvm@...r.kernel.org>, 
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] KVM: x86: skip userspace IOAPIC EOI exit when Directed
 EOI is enabled

On Mon, Nov 03, 2025, Khushit Shah wrote:
> Hi Sean, 
> 
> > On 31 Oct 2025, at 10:58 PM, Sean Christopherson <seanjc@...gle.com> wrote:
> > 
> >> Hi Sean,
> >> 
> >> Thanks for the reply.
> >> 
> >>> On 25 Oct 2025, at 1:51 AM, Sean Christopherson <seanjc@...gle.com> wrote:
> >>> 
> >>> Make it a quirk instead of a capability.  This is definitely a KVM bug, it's just
> >>> unfortunately one that we can't fix without breaking userspace :-/
> >> 
> >> I don’t think this approach fully addresses the issue.
> >> 
> >> For example, consider the same Windows guest running with a userspace
> >> I/O APIC that has no EOI registers. The guest will set the Suppress EOI
> >> Broadcast bit because KVM advertises support for it (see 
> >> kvm_apic_set_version).
> >> 
> >> If the quirk is enabled, an interrupt storm will occur.
> >> If the quirk is disabled, userspace will never receive the EOI
> >> notification.
> > 
> > Uh, why not?
> > 
> >> For context, Windows with CG the interrupt 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.
> > 
> > And at #5, the MMIO access to the I/O APIC gets routed to userspace for emulation.
> 
> Yes, but the userspace does not have I/O APIC EOI register and so it will just be a
> meaningless MMIO write, resulting in the the IRQ line being kept masked.

Why on earth would userspace disable the quirk without proper support?

> > On 31 Oct 2025, at 10:58 PM, Sean Christopherson <seanjc@...gle.com> wrote:
> > 
> > That's the whole point of the quirk; userspace should disable the quirk if and
> > only if it supports the I/O APIC EOI extension.
> 
> 
> Sadly, so if the quirk is kept enabled (no I/O APIC EOI extension) and if we do
> not want a guest reboot, the original windows interrupt storm bug will persist?

Well, yeah, if you don't fix the bug it'll keep causing problems.

> Unless we also update the userspace to handle the EOI register write nonetheless,
> as damage has been done on the time of power on.
> 
> > On 31 Oct 2025, at 10:58 PM, Sean Christopherson <seanjc@...gle.com> wrote:
> > 
> >> and updated userspace can opt in when it truly supports EOI broadcast
> >> suppression.
> >> 
> >> Am I missing something?
> > 
> > I think so?  It's also possible I'm missing something :-)
> 
> I am just thinking that the original Windows bug is not solved for all the cases,
> i.e A powered on Windows guest with userspace I/O APIC that does not have
> EOI register. 

Userspace _must_ change one way or the other.  Either that or you livepatch your
kernel to carry an out-of-tree hack-a-fix to avoid updating userspace. 

> Also, in the patch instead of a knob to disable suppress EOI broadcast, I think
> we should have a knob to enable, this way at least for unmodified userspace 
> the buggy situation is never reached.

No.  Having a bug that prevents booting certain guests is bad.  Introducing a
change that potentially breaks existing setups is worse.  Yes, it's unfortunate
that userspace needs to be updated to fully remedy the issue.  But unless you're
livepatching the kernel, userspace should be updated anyways on a full reboot.