linux-kernel - Re: [PATCH 02/34] KVM: Assert that mmu_invalidate_in

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: <4e64f7f303ac25ba3bfadeecf8422340a62ec1d0.camel@intel.com>
Date:   Mon, 6 Nov 2023 09:29:19 +0000
From:   "Huang, Kai" <kai.huang@...el.com>
To:     "viro@...iv.linux.org.uk" <viro@...iv.linux.org.uk>,
        "Christopherson,, Sean" <seanjc@...gle.com>,
        "brauner@...nel.org" <brauner@...nel.org>,
        "oliver.upton@...ux.dev" <oliver.upton@...ux.dev>,
        "chenhuacai@...nel.org" <chenhuacai@...nel.org>,
        "palmer@...belt.com" <palmer@...belt.com>,
        "aou@...s.berkeley.edu" <aou@...s.berkeley.edu>,
        "maz@...nel.org" <maz@...nel.org>,
        "pbonzini@...hat.com" <pbonzini@...hat.com>,
        "mpe@...erman.id.au" <mpe@...erman.id.au>,
        "paul.walmsley@...ive.com" <paul.walmsley@...ive.com>,
        "anup@...infault.org" <anup@...infault.org>,
        "willy@...radead.org" <willy@...radead.org>,
        "akpm@...ux-foundation.org" <akpm@...ux-foundation.org>
CC:     "Li, Xiaoyao" <xiaoyao.li@...el.com>,
        "kvm-riscv@...ts.infradead.org" <kvm-riscv@...ts.infradead.org>,
        "mic@...ikod.net" <mic@...ikod.net>,
        "liam.merwick@...cle.com" <liam.merwick@...cle.com>,
        "kvm@...r.kernel.org" <kvm@...r.kernel.org>,
        "Yamahata, Isaku" <isaku.yamahata@...el.com>,
        "kirill.shutemov@...ux.intel.com" <kirill.shutemov@...ux.intel.com>,
        "david@...hat.com" <david@...hat.com>,
        "tabba@...gle.com" <tabba@...gle.com>,
        "amoorthy@...gle.com" <amoorthy@...gle.com>,
        "linuxppc-dev@...ts.ozlabs.org" <linuxppc-dev@...ts.ozlabs.org>,
        "michael.roth@....com" <michael.roth@....com>,
        "kvmarm@...ts.linux.dev" <kvmarm@...ts.linux.dev>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "linux-fsdevel@...r.kernel.org" <linux-fsdevel@...r.kernel.org>,
        "linux-riscv@...ts.infradead.org" <linux-riscv@...ts.infradead.org>,
        "chao.p.peng@...ux.intel.com" <chao.p.peng@...ux.intel.com>,
        "linux-mips@...r.kernel.org" <linux-mips@...r.kernel.org>,
        "Annapurve, Vishal" <vannapurve@...gle.com>,
        "vbabka@...e.cz" <vbabka@...e.cz>,
        "mail@...iej.szmigiero.name" <mail@...iej.szmigiero.name>,
        "yu.c.zhang@...ux.intel.com" <yu.c.zhang@...ux.intel.com>,
        "qperret@...gle.com" <qperret@...gle.com>,
        "dmatlack@...gle.com" <dmatlack@...gle.com>,
        "Xu, Yilun" <yilun.xu@...el.com>,
        "isaku.yamahata@...il.com" <isaku.yamahata@...il.com>,
        "ackerleytng@...gle.com" <ackerleytng@...gle.com>,
        "jarkko@...nel.org" <jarkko@...nel.org>,
        "linux-arm-kernel@...ts.infradead.org" 
        <linux-arm-kernel@...ts.infradead.org>,
        "linux-mm@...ck.org" <linux-mm@...ck.org>,
        "Wang, Wei W" <wei.w.wang@...el.com>
Subject: Re: [PATCH 02/34] KVM: Assert that mmu_invalidate_in_progress *never*
 goes negative

On Sun, 2023-11-05 at 17:30 +0100, Paolo Bonzini wrote:
> From: Sean Christopherson <seanjc@...gle.com>
> 
> Move the assertion on the in-progress invalidation count from the primary
> MMU's notifier path to KVM's common notification path, i.e. assert that
> the count doesn't go negative even when the invalidation is coming from
> KVM itself.
> 
> Opportunistically convert the assertion to a KVM_BUG_ON(), i.e. kill only
> the affected VM, not the entire kernel.  A corrupted count is fatal to the
> VM, e.g. the non-zero (negative) count will cause mmu_invalidate_retry()
> to block any and all attempts to install new mappings.  But it's far from
> guaranteed that an end() without a start() is fatal or even problematic to
> anything other than the target VM, e.g. the underlying bug could simply be
> a duplicate call to end().  And it's much more likely that a missed
> invalidation, i.e. a potential use-after-free, would manifest as no
> notification whatsoever, not an end() without a start().
> 
> Signed-off-by: Sean Christopherson <seanjc@...gle.com>
> Reviewed-by: Paolo Bonzini <pbonzini@...hat.com>
> Reviewed-by: Fuad Tabba <tabba@...gle.com>
> Tested-by: Fuad Tabba <tabba@...gle.com>
> Message-Id: <20231027182217.3615211-3-seanjc@...gle.com>
> Signed-off-by: Paolo Bonzini <pbonzini@...hat.com>
> 

Reviewed-by: Kai Huang <kai.huang@...el.com>