linux-kernel - Re: [RFC PATCH] KVM: x86: inhibit APICv upon detecting direct APIC access from L2

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: <ZNEyQM8CYSAcyt9F@google.com>
Date:   Mon, 7 Aug 2023 11:04:48 -0700
From:   Sean Christopherson <seanjc@...gle.com>
To:     Maxim Levitsky <mlevitsk@...hat.com>
Cc:     Ake Koomsin <ake@...l.co.jp>, kvm@...r.kernel.org,
        linux-kernel@...r.kernel.org, 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>,
        "H . Peter Anvin" <hpa@...or.com>
Subject: Re: [RFC PATCH] KVM: x86: inhibit APICv upon detecting direct APIC
 access from L2

On Mon, Aug 07, 2023, Maxim Levitsky wrote:
> У пн, 2023-08-07 у 15:26 +0900, Ake Koomsin пише:
> > Current KVM does not expect L1 hypervisor to allow L2 guest to access
> > APIC page directly when APICv is enabled. When this happens, KVM
> > emulates the access itself resulting in interrupt lost.

Kinda stating the obvious, but as Maxim alluded to, emulating an APIC access while
APICv is active should not result in lost interrupts.  I.e. suppressing APICv is
likely masking a bug that isn't unique to this specific scenario.

> Is there a good reason why KVM doesn't expose APIC memslot to a nested guest?

AFAIK, simply because no one has ever requested that KVM support such a use case.

> While nested guest runs, the L1's APICv is "inhibited" effectively anyway, so
> writes to this memslot should update APIC registers and be picked up by APICv
> hardware when L1 resumes execution.
> 
> Since APICv alows itself to be inhibited due to other reasons, it means that
> just like AVIC, it should be able to pick up arbitrary changes to APIC
> registers which happened while it was inhibited, just like AVIC does.
> 
> I'll take a look at the code to see if APICv does this (I know AVIC's code
> much better that APICv's)
> 
> Is there a reproducer for this bug?

+1, this needs a reproducer, or at the very least a very detailed explanation
and analysis.