linux-kernel - Re: [PATCH 5/6] KVM: x86: never clear irr_pending in kvm_apic_update

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: <636dd644-8160-645a-ce5a-f4eb344f001c@redhat.com>
Date:   Fri, 10 Dec 2021 13:07:52 +0100
From:   Paolo Bonzini <pbonzini@...hat.com>
To:     Maxim Levitsky <mlevitsk@...hat.com>, kvm@...r.kernel.org
Cc:     "open list:X86 ARCHITECTURE (32-BIT AND 64-BIT)" 
        <linux-kernel@...r.kernel.org>, Wanpeng Li <wanpengli@...cent.com>,
        Dave Hansen <dave.hansen@...ux.intel.com>,
        Joerg Roedel <joro@...tes.org>,
        "H. Peter Anvin" <hpa@...or.com>,
        Vitaly Kuznetsov <vkuznets@...hat.com>,
        Borislav Petkov <bp@...en8.de>,
        "maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT)" <x86@...nel.org>,
        Ingo Molnar <mingo@...hat.com>,
        Thomas Gleixner <tglx@...utronix.de>,
        Jim Mattson <jmattson@...gle.com>,
        Sean Christopherson <seanjc@...gle.com>
Subject: Re: [PATCH 5/6] KVM: x86: never clear irr_pending in
 kvm_apic_update_apicv

On 12/9/21 12:54, Maxim Levitsky wrote:
> It is possible that during the AVIC incomplete IPI vmexit,
> its handler will set irr_pending to true,
> but the target vCPU will still see the IRR bit not set,
> due to the apparent lack of memory ordering between CPU's vIRR write
> that is supposed to happen prior to the AVIC incomplete IPI
> vmexit and the write of the irr_pending in that handler.

Are you sure about this?  Store-to-store ordering should be 
guaranteed---if not by the architecture---by existing memory barriers 
between vmrun returning and avic_incomplete_ipi_interception().  For 
example, srcu_read_lock implies an smp_mb().

Even more damning: no matter what internal black magic the processor 
could be using to write to IRR, the processor needs to order the writes 
against reads of IsRunning on processors without the erratum.  That 
would be equivalent to flushing the store buffer, and it would imply 
that the write of vIRR is ordered before the write to irr_pending.

Paolo