From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id C5F167B for ; Tue, 25 Apr 2023 12:14:20 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 22164C4339C; Tue, 25 Apr 2023 12:14:18 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1682424860; bh=cHsYInE/5/VtMOx1jRJroZVHEJ5p4Z38kwQmVafczdI=; h=From:To:Cc:Subject:Date:From; b=vQnJT5OfIlwg15X4GF4Lg28xNLib8xCxrp5enROuXv+LYcoU8+DXtnERaiK5LxtjO RvGpbQXFssaoyTbMB4ZDgmHuSkyqczogW7oCGQj8Qbe41hOsprAdOHrXRWxSVK9kDg 6Eo2ahWBYNv01po+ffGhuvAXgaIoI68pFF0bu6D/Mkzn8gl3U/jvGziSSwwb8cFtFo I9Ry5tDYFxen4vYEczEmRFEIGfQqVAQa70vSWKrvATnpOMWBLtfKUO63dLL4yaTOae 1oL4B4IAAHA37nM2vGxs3wjW2SHm/x2NU4pDHfKRCSWEktl45X0OkBD1NIZOTNsoMT hudtP//wd4xKA== From: Will Deacon To: stable@vger.kernel.org Cc: gregkh@linuxfoundation.org, kvmarm@lists.linux.dev, David Matlack , Sean Christopherson , Marc Zyngier , Oliver Upton , Will Deacon Subject: [BACKPORT PATCH 5.15.y] KVM: arm64: Retry fault if vma_lookup() results become invalid Date: Tue, 25 Apr 2023 13:14:13 +0100 Message-Id: <20230425121413.8544-1-will@kernel.org> X-Mailer: git-send-email 2.20.1 Precedence: bulk X-Mailing-List: kvmarm@lists.linux.dev List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit From: David Matlack [ Upstream commit 13ec9308a85702af7c31f3638a2720863848a7f2 ] Read mmu_invalidate_seq before dropping the mmap_lock so that KVM can detect if the results of vma_lookup() (e.g. vma_shift) become stale before it acquires kvm->mmu_lock. This fixes a theoretical bug where a VMA could be changed by userspace after vma_lookup() and before KVM reads the mmu_invalidate_seq, causing KVM to install page table entries based on a (possibly) no-longer-valid vma_shift. Re-order the MMU cache top-up to earlier in user_mem_abort() so that it is not done after KVM has read mmu_invalidate_seq (i.e. so as to avoid inducing spurious fault retries). This bug has existed since KVM/ARM's inception. It's unlikely that any sane userspace currently modifies VMAs in such a way as to trigger this race. And even with directed testing I was unable to reproduce it. But a sufficiently motivated host userspace might be able to exploit this race. Fixes: 94f8e6418d39 ("KVM: ARM: Handle guest faults in KVM") Cc: stable@vger.kernel.org # 5.15 only Reported-by: Sean Christopherson Signed-off-by: David Matlack Reviewed-by: Marc Zyngier Link: https://lore.kernel.org/r/20230313235454.2964067-1-dmatlack@google.com Signed-off-by: Oliver Upton [will: Use FSC_PERM instead of ESR_ELx_FSC_PERM. Read 'mmu_notifier_seq' instead of 'mmu_invalidate_seq'. Fix up function references in comment.] Signed-off-by: Will Deacon --- arch/arm64/kvm/mmu.c | 47 ++++++++++++++++++++------------------------ 1 file changed, 21 insertions(+), 26 deletions(-) diff --git a/arch/arm64/kvm/mmu.c b/arch/arm64/kvm/mmu.c index 9b465cd55a8d..38a8095744a0 100644 --- a/arch/arm64/kvm/mmu.c +++ b/arch/arm64/kvm/mmu.c @@ -997,6 +997,20 @@ static int user_mem_abort(struct kvm_vcpu *vcpu, phys_addr_t fault_ipa, return -EFAULT; } + /* + * Permission faults just need to update the existing leaf entry, + * and so normally don't require allocations from the memcache. The + * only exception to this is when dirty logging is enabled at runtime + * and a write fault needs to collapse a block entry into a table. + */ + if (fault_status != FSC_PERM || + (logging_active && write_fault)) { + ret = kvm_mmu_topup_memory_cache(memcache, + kvm_mmu_cache_min_pages(kvm)); + if (ret) + return ret; + } + /* * Let's check if we will get back a huge page backed by hugetlbfs, or * get block mapping for device MMIO region. @@ -1051,36 +1065,17 @@ static int user_mem_abort(struct kvm_vcpu *vcpu, phys_addr_t fault_ipa, fault_ipa &= ~(vma_pagesize - 1); gfn = fault_ipa >> PAGE_SHIFT; - mmap_read_unlock(current->mm); - - /* - * Permission faults just need to update the existing leaf entry, - * and so normally don't require allocations from the memcache. The - * only exception to this is when dirty logging is enabled at runtime - * and a write fault needs to collapse a block entry into a table. - */ - if (fault_status != FSC_PERM || (logging_active && write_fault)) { - ret = kvm_mmu_topup_memory_cache(memcache, - kvm_mmu_cache_min_pages(kvm)); - if (ret) - return ret; - } - mmu_seq = vcpu->kvm->mmu_notifier_seq; /* - * Ensure the read of mmu_notifier_seq happens before we call - * gfn_to_pfn_prot (which calls get_user_pages), so that we don't risk - * the page we just got a reference to gets unmapped before we have a - * chance to grab the mmu_lock, which ensure that if the page gets - * unmapped afterwards, the call to kvm_unmap_gfn will take it away - * from us again properly. This smp_rmb() interacts with the smp_wmb() - * in kvm_mmu_notifier_invalidate_. + * Read mmu_notifier_seq so that KVM can detect if the results of + * vma_lookup() or __gfn_to_pfn_memslot() become stale prior to + * acquiring kvm->mmu_lock. * - * Besides, __gfn_to_pfn_memslot() instead of gfn_to_pfn_prot() is - * used to avoid unnecessary overhead introduced to locate the memory - * slot because it's always fixed even @gfn is adjusted for huge pages. + * Rely on mmap_read_unlock() for an implicit smp_rmb(), which pairs + * with the smp_wmb() in kvm_dec_notifier_count(). */ - smp_rmb(); + mmu_seq = vcpu->kvm->mmu_notifier_seq; + mmap_read_unlock(current->mm); pfn = __gfn_to_pfn_memslot(memslot, gfn, false, NULL, write_fault, &writable, NULL); -- 2.40.0.634.g4ca3ef3211-goog