linux-kernel - Re: [PATCH] KVM: Don't actually set a request when evicting vCPUs for GFN cache invd

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]

Date:   Mon, 14 Feb 2022 18:50:29 +0000
From:   David Woodhouse <dwmw2@...radead.org>
To:     Sean Christopherson <seanjc@...gle.com>
Cc:     Paolo Bonzini <pbonzini@...hat.com>,
        Christian Borntraeger <borntraeger@...ux.ibm.com>,
        Janosch Frank <frankja@...ux.ibm.com>,
        David Hildenbrand <david@...hat.com>,
        Claudio Imbrenda <imbrenda@...ux.ibm.com>,
        "kvm@...r.kernel.org" <kvm@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] KVM: Don't actually set a request when evicting vCPUs
 for GFN cache invd

On Mon, 2022-02-14 at 17:14 +0000, Sean Christopherson wrote:
> On Sat, Feb 12, 2022, Woodhouse, David wrote:
> > (Apologies if this is HTML but I'm half-way to Austria and the laptop is
> > buried somewhere in the car, and access to work email with sane email apps is
> > difficult.)
> > 
> > On 12 Feb 2022 03:05, Sean Christopherson <seanjc@...gle.com> wrote:
> > 
> > Don't actually set a request bit in vcpu->requests when making a request
> > purely to force a vCPU to exit the guest.  Logging the request but not
> > actually consuming it causes the vCPU to get stuck in an infinite loop
> > during KVM_RUN because KVM sees a pending request and bails from VM-Enter
> > to service the request.
> > 
> > 
> > Right, but there is no extant code which does this. The guest_uses_pa flag is
> > unused.
> 
> Grr.  A WARN or something would have been nice to have.  Oh well.

I don't think it was clear yet what the 'wrong' behaviour would we that
we should warn about, since we really hadn't finished defining the
'correct' usage :)

> > The series came with a proof-of-concept that attempted using it for
> > fixing nesting UAFs but it was just that — a proof of concept to demonstrate
> > that the new design of GPC was sufficient to address that problem.
> > 
> > IIRC, said proof of concept did also actually consume the req in question,
> 
> It did.  I saw that, but obviously didn't connect the dots to guest_uses_pa.
> 
> --- a/arch/x86/kvm/x86.c
> +++ b/arch/x86/kvm/x86.c
> @@ -9826,6 +9826,8 @@ static int vcpu_enter_guest(struct kvm_vcpu *vcpu)
> 
>                 if (kvm_check_request(KVM_REQ_UPDATE_CPU_DIRTY_LOGGING, vcpu))
>                         static_call(kvm_x86_update_cpu_dirty_logging)(vcpu);
> +               if (kvm_check_request(KVM_REQ_GPC_INVALIDATE, vcpu))
> +                       ; /* Nothing to do. It just wanted to wake us */
> 

Right. That's a later iteration. I originally *did* actually use it to
trigger an action, IIRC, but Paolo suggested we do it differently.

I also pondered having each GPC able to raise a specific request, and
set the KVM_REQ_xxx bit in the GPC itself. That just made the loop in
invalidate_start() a bit more complex though because of the way that it
wakes the vCPUs after it's done its iteration and collected them in a
cpumask. So it seemed like premature deoptimisation; we can add that in
future if we really do need it, and looks like we're going in the
opposite direction.

> > and one of the existing test cases did exercise it with an additional mmap
> > torture added? Of course until we have kernel code that *does* this, it's
> > hard to exercise it from userspace :)
> 
> Indeed.  I'll send a new version with a different changelog, that way we're not
> leaving a trap for developers and each architecture doesn't need to manually handle
> the request.

Ack, thanks.

Download attachment "smime.p7s" of type "application/pkcs7-signature" (5965 bytes)