linux-kernel - [PATCH v8 2/6] KVM: arm64: Update the check to detect device memory

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: <20250620120946.2991-3-ankita@nvidia.com>
Date: Fri, 20 Jun 2025 12:09:42 +0000
From: <ankita@...dia.com>
To: <ankita@...dia.com>, <jgg@...dia.com>, <maz@...nel.org>,
	<oliver.upton@...ux.dev>, <joey.gouly@....com>, <suzuki.poulose@....com>,
	<yuzenghui@...wei.com>, <catalin.marinas@....com>, <will@...nel.org>,
	<ryan.roberts@....com>, <shahuang@...hat.com>, <lpieralisi@...nel.org>,
	<david@...hat.com>, <ddutile@...hat.com>, <seanjc@...gle.com>
CC: <aniketa@...dia.com>, <cjia@...dia.com>, <kwankhede@...dia.com>,
	<kjaju@...dia.com>, <targupta@...dia.com>, <vsethi@...dia.com>,
	<acurrid@...dia.com>, <apopple@...dia.com>, <jhubbard@...dia.com>,
	<danw@...dia.com>, <zhiw@...dia.com>, <mochs@...dia.com>,
	<udhoke@...dia.com>, <dnigam@...dia.com>, <alex.williamson@...hat.com>,
	<sebastianene@...gle.com>, <coltonlewis@...gle.com>, <kevin.tian@...el.com>,
	<yi.l.liu@...el.com>, <ardb@...nel.org>, <akpm@...ux-foundation.org>,
	<gshan@...hat.com>, <linux-mm@...ck.org>, <tabba@...gle.com>,
	<qperret@...gle.com>, <kvmarm@...ts.linux.dev>,
	<linux-kernel@...r.kernel.org>, <linux-arm-kernel@...ts.infradead.org>,
	<maobibo@...ngson.cn>
Subject: [PATCH v8 2/6] KVM: arm64: Update the check to detect device memory

From: Ankit Agrawal <ankita@...dia.com>

Currently, the kvm_is_device_pfn() detects if the memory is kernel
mapped through pfn_is_map_memory. It thus implies whether KVM can
use Cache Maintenance Operations (CMOs) on that PFN. It is a bit
of a misnomer as it does not necessarily detect whether a PFN
is for a device memory. Moreover, the function is only used at
one place.

It would be better to directly call pfn_is_map_memory. Moreover
we should restrict this call to VM_PFNMAP or VM_MIXEDMAP. Otherwise
the VMA has struct pages in it and mapped in the kernel VA.

Suggested-by: Jason Gunthorpe <jgg@...dia.com>
Signed-off-by: Ankit Agrawal <ankita@...dia.com>
---
 arch/arm64/kvm/mmu.c | 10 ++++------
 1 file changed, 4 insertions(+), 6 deletions(-)

diff --git a/arch/arm64/kvm/mmu.c b/arch/arm64/kvm/mmu.c
index 1601ab9527d4..5fe24f30999d 100644
--- a/arch/arm64/kvm/mmu.c
+++ b/arch/arm64/kvm/mmu.c
@@ -193,11 +193,6 @@ int kvm_arch_flush_remote_tlbs_range(struct kvm *kvm,
 	return 0;
 }
 
-static bool kvm_is_device_pfn(unsigned long pfn)
-{
-	return !pfn_is_map_memory(pfn);
-}
-
 static void *stage2_memcache_zalloc_page(void *arg)
 {
 	struct kvm_mmu_memory_cache *mc = arg;
@@ -1492,6 +1487,7 @@ static int user_mem_abort(struct kvm_vcpu *vcpu, phys_addr_t fault_ipa,
 	enum kvm_pgtable_prot prot = KVM_PGTABLE_PROT_R;
 	struct kvm_pgtable *pgt;
 	struct page *page;
+	vm_flags_t vm_flags;
 	enum kvm_pgtable_walk_flags flags = KVM_PGTABLE_WALK_HANDLE_FAULT | KVM_PGTABLE_WALK_SHARED;
 
 	if (fault_is_perm)
@@ -1619,6 +1615,8 @@ static int user_mem_abort(struct kvm_vcpu *vcpu, phys_addr_t fault_ipa,
 
 	vfio_allow_any_uc = vma->vm_flags & VM_ALLOW_ANY_UNCACHED;
 
+	vm_flags = vma->vm_flags;
+
 	/* Don't use the VMA after the unlock -- it may have vanished */
 	vma = NULL;
 
@@ -1642,7 +1640,7 @@ static int user_mem_abort(struct kvm_vcpu *vcpu, phys_addr_t fault_ipa,
 	if (is_error_noslot_pfn(pfn))
 		return -EFAULT;
 
-	if (kvm_is_device_pfn(pfn)) {
+	if (vm_flags & (VM_PFNMAP | VM_MIXEDMAP) && !pfn_is_map_memory(pfn)) {
 		/*
 		 * If the page was identified as device early by looking at
 		 * the VMA flags, vma_pagesize is already representing the
-- 
2.34.1