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 --- 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