Re: [PATCH] KVM: arm64: Prevent FWD_TO_USER of SMCCC to pKVM

[Marc Zyngier <maz@kernel.org>]

On Mon, 01 Dec 2025 18:19:52 +0000,
"=?utf-8?q?Pierre-Cl=C3=A9ment_Tosi?=" <ptosi@google.com> wrote:
> 
> 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 KVM FID range (which pKVM re-uses).
> 
> DEN0028 defines 65536 "Vendor Specific Hypervisor Service Calls":
> 
> - the first ARM_SMCCC_KVM_NUM_FUNCS (128) can be custom-defined
> - the following 3 are currently standardized
> - the rest is "reserved for future expansion"
> 
> so reserve them all, like commit 821d935c87bc ("KVM: arm64: Introduce
> support for userspace SMCCC filtering") with the Arm Architecture Calls.

I don't think preventing all hypercalls from reaching userspace is
acceptable from an API perspective. For example, it is highly expected
that the hypercall that exposes the various MIDR/REVIDR/AIDR that the
guest can be expected to run on is handled in userspace.

Given that this hypercall is critical to the correct behaviour of a
guest in an asymmetric system, you can't really forbid it. If you
don't want it, that's fine -- don't implement it in your VMM.

But I fully expect pKVM to inherit the existing APIs by virtue of
being a KVM backend.

> Alternatively, we could have only reserved the ARM_SMCCC_KVM_NUM_FUNCS
> (or even a subset of it) and the "Call UID Query" but that would have
> risked future conflicts between that uAPI and an extension of the SMCCC
> or of the pKVM ABI.

I disagree. The only ones you can legitimately block are the ones that
are earmarked for pKVM itself (2-63), and only these. Everything else
should make it to userspace if the guest and the VMM agree to do so.

This is part of the KVM ABI, and pKVM should be fixed.

Thanks,

	M.

-- 
Without deviation from the norm, progress is not possible.