Re: [PATCH v1 11/11] KVM: arm64: Tag host-VA hypercall parameters __hostva

[sashiko-bot@kernel.org]

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

New issues:
- [Medium] `kern_hyp_va_host()` macro fails to strip the `__hostva` address space tag for Sparse.

Pre-existing issues:
- [Critical] Missing host pointer ownership validation in always-on hypercalls allows a malicious host to corrupt EL2-private memory (Confused Deputy).
--

--- Patch [11]: [PATCH v1 11/11] KVM: arm64: Tag host-VA hypercall parameters __hostva ---
commit 4acf0dff6116caffddce5517211ac9136d9b0ee1
Author: Fuad Tabba <fuad.tabba@linux.dev>

KVM: arm64: Tag host-VA hypercall parameters __hostva

This commit introduces the __hostva sparse address space to tag host virtual
addresses passed as hypercall arguments in the nVHE hypervisor. It adds
kern_hyp_va_host() to explicitly unwrap and translate these tagged pointers,
ensuring that untranslated host VAs are caught by sparse checks.

> diff --git a/arch/arm64/include/asm/kvm_mmu.h b/arch/arm64/include/asm/kvm_mmu.h
> --- a/arch/arm64/include/asm/kvm_mmu.h
> +++ b/arch/arm64/include/asm/kvm_mmu.h

[ ... ]

> @@ -140,6 +142,14 @@ static __always_inline unsigned long __kern_hyp_va(unsigned long v)
>  
>  #define kern_hyp_va(v) 	((typeof(v))(__kern_hyp_va((unsigned long)(v))))
>  
> +/*
> + * Translate a __hostva-tagged host VA, dropping the tag: the only sanctioned
> + * unwrap. Translation only, no ownership or bounds validation; the result
> + * carries the pointee type stripped of the tag and of any cv-qualifiers.
> + */
> +#define kern_hyp_va_host(v)						\
> +	((TYPEOF_UNQUAL(*(v)) *)__kern_hyp_va((unsigned long)(__force void *)(v)))

[Severity: Medium]
Does TYPEOF_UNQUAL() actually strip the address space tag in Sparse?

Sparse treats address spaces as type qualifiers that typeof_unqual (and
by extension TYPEOF_UNQUAL) does not remove, unlike const or volatile.
Consequently, this cast evaluates to a pointer that still carries the
__hostva tag.

When assigned to a regular kernel pointer, this will trigger incorrect type
in assignment (different address spaces) false positive warnings across the
codebase when running make C=2.

Should this use an explicit cast to __kernel (address_space(0)) to
correctly strip the tag, similar to how per_cpu_ptr handles __percpu?

> 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

[ ... ]

> @@ -421,9 +421,9 @@ DEFINE_KVM_HOST_HCALL(int, __pkvm_host_mkyoung_guest, 1,
>  }
>  
>  DEFINE_KVM_HOST_HCALL_VOID(__kvm_adjust_pc, 1,
> -	struct kvm_vcpu *, vcpu)
> +	struct kvm_vcpu __hostva *, vcpu)
>  {
> -	__kvm_adjust_pc(kern_hyp_va(vcpu));
> +	__kvm_adjust_pc(kern_hyp_va_host(vcpu));
>  }

[Severity: Critical]
This is a pre-existing issue, but does this lack of ownership validation
allow the host to corrupt EL2-private memory?

Under pKVM, the host is treated as an adversary. If the host provides a
TTBR1 virtual address that maps to an EL2-private physical address,
kern_hyp_va_host() will translate it into a valid EL2 linear map pointer
without verifying ownership. 

The hypervisor will then write into EL2-private memory when modifying
flags in __kvm_adjust_pc() or hardware register state in
__vgic_v3_save_aprs(), corrupting its own state or the state of
protected guests.

Should there be an explicit ownership check before dereferencing
pointers from these always-on hypercalls?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260720162412.1401272-1-fuad.tabba@linux.dev?part=11