linux-kernel - Re: [PATCH V2] KVM:x86:Fix an interrupt injection logic error during PIC interrupt simulation

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: <Z66RC673dzlq2YuA@google.com>
Date: Thu, 13 Feb 2025 16:40:43 -0800
From: Sean Christopherson <seanjc@...gle.com>
To: Liam Ni <zhiguangni01@...il.com>
Cc: 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, 
	"H. Peter Anvin" <hpa@...or.com>, kvm@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH V2] KVM:x86:Fix an interrupt injection logic error during
 PIC interrupt simulation

On Tue, Jul 30, 2024, Liam Ni wrote:
> The input parameter level to the pic_irq_request function indicates
> whether there are interrupts to be injected,
> a level value of 1 indicates that there are interrupts to be injected,
> and a level value of 0 indicates that there are no interrupts to be injected.
> And the value of level will be assigned to s->output,
> so we should set s->wakeup_needed to true when s->output is true.

Neither the shortlog nor the changelog actually explains the impact of the bug,
or even what's being fixed.  I rewrote it to this:

    KVM: x86: Wake vCPU for PIC interrupt injection iff a valid IRQ was found

    When updating the emulated PIC IRQ status, set "wakeup_needed" if and only
    if a new interrupt was found, i.e. if the incoming level is non-zero and
    an IRQ is being raised.  The bug is relatively benign, as KVM will signal
    a spurious wakeup, e.g. set KVM_REQ_EVENT and kick target vCPUs, but KVM
    will never actually inject a spurious IRQ as kvm_cpu_has_extint() cares
    only about the "output" field.

And that's of particular interest because this fix uncovered a latent bug in
nested VMX.  If an IRQ becomes pending while L2 is running, and the IRQ must be
injected (e.g. APICv is disabled), KVM fails to request KVM_REQ_EVENT and so
doesn't trigger an IRQ window.  But the spurious KVM_REQ_EVENT from
pic_irq_request() masks the bug (I didn't bother tracking down how pic_irq_request()
is getting invoked on nested VM-Exit).

I'm applying the patch in advance of the nVMX fix, because the PIC emulation goof
only helps with fully in-kernel IRQCHIP, i.e. if the PIC and I/O APIC are emulated
by KVM.  E.g. the vmx_apic_passthrough_tpr_threshold_test KVM-Unit-Test fails even
without this change if it's run with a split IRQCHIP.

That said, I'll ensure the nVMX fix lands upstream before this (I'm planning on
tagging it for stable and routing it into 6.14).

> Signed-off-by: Liam Ni <zhiguangni01@...il.com>
> ---
>  arch/x86/kvm/i8259.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/arch/x86/kvm/i8259.c b/arch/x86/kvm/i8259.c
> index 8dec646e764b..ec9d6ee7d33d 100644
> --- a/arch/x86/kvm/i8259.c
> +++ b/arch/x86/kvm/i8259.c
> @@ -567,7 +567,7 @@ static void pic_irq_request(struct kvm *kvm, int level)
>  {
>     struct kvm_pic *s = kvm->arch.vpic;
> 
> -   if (!s->output)
> +   if (!s->output && level)
>         s->wakeup_needed = true;
>     s->output = level;
>  }
> --
> 2.34.1