Re: [PATCH 6/8] KVM: arm64: Minimise EL2's exposure of host VGIC state during world switch

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:

Pre-existing issues:
- [Critical] Missing trust boundary validation for host-provided pointers in several hypercalls (`handle___vgic_v5_save_apr`, `handle___vgic_v5_restore_vmcr_apr`, `handle___kvm_adjust_pc`, `handle___kvm_tlb_flush_vmid_ipa`), leading to arbitrary EL2 memory dereference.
--

commit 5fa49efc0aabdcdf925969737165624792f92f6c
Author: Marc Zyngier <maz@kernel.org>
KVM: arm64: Minimise EL2's exposure of host VGIC state during world switch

This patch minimises EL2's exposure of host VGIC state by recovering the host
vCPU from the supplied cpu_if via container_of() and copying only the
necessary registers. This avoids directly dereferencing the host's
vgic_v3_cpu_if pointer.

> diff --git a/arch/arm64/kvm/hyp/nvhe/hyp-main.c b/arch/arm64/kvm/hyp/nvhe/hyp-main.c
> --- a/arch/arm64/kvm/hyp/nvhe/hyp-main.c
> +++ b/arch/arm64/kvm/hyp/nvhe/hyp-main.c

[ ... ]

>  static void handle___kvm_adjust_pc(struct kvm_cpu_context *host_ctxt)
>  {
>  	DECLARE_REG(struct kvm_vcpu *, vcpu, host_ctxt, 1);
>  
>  	__kvm_adjust_pc(kern_hyp_va(vcpu));
>  }

[Severity: Critical]
This is a pre-existing issue, but while this patch fixes the trust boundary
for the VGIC v3 aprs hypercalls, other always-on hypercalls like
handle___kvm_adjust_pc() still unconditionally use kern_hyp_va() on
host-provided pointers.

Can a malicious host provide a crafted EL2 linear-map pointer (for example,
the address of a protected VM's vCPU) here? Since kern_hyp_va() is idempotent
for linear-map objects, it leaves the pointer as-is.

This would allow the host to dereference this pointer, potentially modifying
protected guest state via __kvm_adjust_pc() and bypassing pKVM isolation.

[ ... ]

>  static void handle___kvm_tlb_flush_vmid_ipa(struct kvm_cpu_context *host_ctxt)
>  {
>  	DECLARE_REG(struct kvm_s2_mmu *, mmu, host_ctxt, 1);
>  	DECLARE_REG(phys_addr_t, ipa, host_ctxt, 2);
>  	DECLARE_REG(int, level, host_ctxt, 3);
>  
>  	__kvm_tlb_flush_vmid_ipa(kern_hyp_va(mmu), ipa, level);
>  }

[Severity: Critical]
This is a pre-existing issue, but similar to the above, does this allow
the host to pass a crafted mmu pointer?

If kern_hyp_va() leaves an EL2 linear-map pointer untouched, could the host
use this to load arbitrary values into hardware registers like VTTBR_EL2 via
__kvm_tlb_flush_vmid_ipa()?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260619070508.802802-1-tabba@google.com?part=6