linux-kernel - [PATCH v2] KVM: arm64: Prevent FWD_TO

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>] [day] [month] [year] [list]

Message-ID: <20251201-smccc-filter-v2-1-03dab737a14d@google.com>
Date: Mon, 01 Dec 2025 21:26:42 +0000
From: "Pierre-Clément Tosi" <ptosi@...gle.com>
To: kvm@...r.kernel.org, linux-doc@...r.kernel.org, 
	linux-kernel@...r.kernel.org, linux-arm-kernel@...ts.infradead.org, 
	kvmarm@...ts.linux.dev
Cc: Joey Gouly <joey.gouly@....com>, Marc Zyngier <maz@...nel.org>, Oliver Upton <oupton@...nel.org>, 
	Suzuki K Poulose <suzuki.poulose@....com>, Vincent Donnefort <vdonnefort@...gle.com>, 
	Will Deacon <will@...nel.org>, Zenghui Yu <yuzenghui@...wei.com>, 
	"Pierre-Clément Tosi" <ptosi@...gle.com>
Subject: [PATCH v2] KVM: arm64: Prevent FWD_TO_USER of SMCCC to pKVM

With protected VMs, forwarding guest HVC/SMCs happens at two interfaces:

     pKVM [EL2] <--> KVM [EL1] <--> VMM [EL0]

so it might be possible for EL0 to successfully register with EL1 to
handle guest SMCCC calls but never see the KVM_EXIT_HYPERCALL, even if
the calls are properly issued by the guest, due to EL2 handling them so
that (host) EL1 never gets a chance to exit to EL0.

Instead, avoid that confusing situation and make userspace fail early by
disallowing KVM_ARM_VM_SMCCC_FILTER-ing calls from protected guests in
the pKVM FID range.

Similarly, reserve the "Call UID Query" to ensure that a malicious host
can't mislead a protected guest into misusing the pKVM ABI, under the
premise that it would be interacting with a different hypervisor ABI, as
hypervisors share the same FID space.

Signed-off-by: Pierre-Clément Tosi <ptosi@...gle.com>
---
Changes in v2:
- Restricted the range to pKVM HVCs & the "Call UID Query"
- Updated docs & removed mention of KVM_VM_TYPE_ARM_PROTECTED
- Link to v1: https://lore.kernel.org/r/20251201-smccc-filter-v1-1-b4831416f8a3@google.com
---
 Documentation/virt/kvm/devices/vm.rst | 10 ++++++++++
 arch/arm64/kvm/hypercalls.c           | 29 +++++++++++++++++++++++++++++
 2 files changed, 39 insertions(+)

diff --git a/Documentation/virt/kvm/devices/vm.rst b/Documentation/virt/kvm/devices/vm.rst
index a4d39fa1b0834b090318250db3b670b0b3174259..28ab2629e7e8f166def6f9efd18e8408ab4a8e63 100644
--- a/Documentation/virt/kvm/devices/vm.rst
+++ b/Documentation/virt/kvm/devices/vm.rst
@@ -400,3 +400,13 @@ will reject attempts to define a filter for any portion of these ranges:
         0x8000_0000 0x8000_FFFF
         0xC000_0000 0xC000_FFFF
         =========== ===============
+
+Protected KVM (pKVM) handles some calls directly and will reject attempts to
+define a filter for a protected VM for any portion of these ranges:
+
+        =========== ===============
+        Start       End (inclusive)
+        =========== ===============
+        0x8600_FF01 0x8600_FF01
+        0xC600_0002 0xC600_003F
+        =========== ===============
diff --git a/arch/arm64/kvm/hypercalls.c b/arch/arm64/kvm/hypercalls.c
index 58c5fe7d757274d9079606fcc378485980c6c0f8..5329772f228d356322863a7150ffa40c25ea1ee2 100644
--- a/arch/arm64/kvm/hypercalls.c
+++ b/arch/arm64/kvm/hypercalls.c
@@ -135,6 +135,12 @@ static bool kvm_smccc_test_fw_bmap(struct kvm_vcpu *vcpu, u32 func_id)
 						   ARM_SMCCC_SMC_64,		\
 						   0, ARM_SMCCC_FUNC_MASK)
 
+#define SMC64_PKVM_RANGE_BEGIN	ARM_SMCCC_VENDOR_HYP_KVM_HYP_MEMINFO_FUNC_ID
+#define SMC64_PKVM_RANGE_END	ARM_SMCCC_CALL_VAL(ARM_SMCCC_FAST_CALL,		\
+						   ARM_SMCCC_SMC_64,		\
+						   ARM_SMCCC_OWNER_VENDOR_HYP,	\
+						   ARM_SMCCC_KVM_FUNC_PKVM_RESV_63)
+
 static int kvm_smccc_filter_insert_reserved(struct kvm *kvm)
 {
 	int r;
@@ -158,6 +164,29 @@ static int kvm_smccc_filter_insert_reserved(struct kvm *kvm)
 	if (r)
 		goto out_destroy;
 
+	/*
+	 * Prevent userspace from registering to handle any SMCCC call in the
+	 * vendor hypervisor range for pVMs, avoiding the confusion of guest
+	 * calls seemingly not resulting in KVM_RUN exits because pKVM handles
+	 * them without ever returning to the host. This is NOT for security.
+	 */
+	if (kvm_vm_is_protected(kvm)) {
+		r = mtree_insert(&kvm->arch.smccc_filter,
+				ARM_SMCCC_VENDOR_HYP_CALL_UID_FUNC_ID,
+				xa_mk_value(KVM_SMCCC_FILTER_HANDLE),
+				GFP_KERNEL_ACCOUNT);
+		if (r)
+			goto out_destroy;
+
+		r = mtree_insert_range(&kvm->arch.smccc_filter,
+				       SMC64_PKVM_RANGE_BEGIN,
+				       SMC64_PKVM_RANGE_END,
+				       xa_mk_value(KVM_SMCCC_FILTER_HANDLE),
+				       GFP_KERNEL_ACCOUNT);
+		if (r)
+			goto out_destroy;
+	}
+
 	return 0;
 out_destroy:
 	mtree_destroy(&kvm->arch.smccc_filter);

---
base-commit: 7d0a66e4bb9081d75c82ec4957c50034cb0ea449
change-id: 20251201-smccc-filter-588ddf12b355

Best regards,
-- 
Pierre-Clément Tosi <ptosi@...gle.com>