linux-kernel - Re: [PATCH] KVM: arm64: Implement KVM

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

Message-ID: <86frcd1tp4.wl-maz@kernel.org>
Date: Tue, 23 Sep 2025 09:03:51 +0100
From: Marc Zyngier <maz@...nel.org>
To: Priscilla Lam <prl@...zon.com>
Cc: <oliver.upton@...ux.dev>,
	<joey.gouly@....com>,
	<suzuki.poulose@....com>,
	<yuzenghui@...wei.com>,
	<dwmw@...zon.co.uk>,
	<gurugubs@...zon.com>,
	<christoffer.dall@....com>,
	<graf@...zon.com>,
	<linux-arm-kernel@...ts.infradead.org>,
	<kvmarm@...ts.linux.dev>,
	<linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] KVM: arm64: Implement KVM_TRANSLATE ioctl for arm64

Hi Priscilla,

On Mon, 22 Sep 2025 21:24:52 +0100,
Priscilla Lam <prl@...zon.com> wrote:
> 
> There is a KVM_TRANSLATE ioctl for x86 to translate a GVA
> (guest virtual address) to a GPA (guest physical address) in EL1
> which is not yet implemented for arm64.
> 
> Implement KVM_TRANSLATE on arm64 for both configurations that
> support and do not support VHE. The VHE path uses the AT
> instruction directly while the non-VHE implementation wraps the
> AT call in a hypercall to allow for its execution in EL2. Add
> selftest that tests the ioctl in both configurations.
> 
> Signed-off-by: Priscilla Lam <prl@...zon.com>
> ---
>  arch/arm64/include/asm/kvm_asm.h              |   2 +
>  arch/arm64/kvm/guest.c                        |  89 ++++++++++++++-
>  arch/arm64/kvm/hyp/nvhe/Makefile              |   3 +-
>  arch/arm64/kvm/hyp/nvhe/hyp-main.c            |  10 ++
>  arch/arm64/kvm/hyp/nvhe/translate.c           |  84 ++++++++++++++
>  tools/testing/selftests/kvm/Makefile.kvm      |   1 +
>  tools/testing/selftests/kvm/arm64/translate.c | 107 ++++++++++++++++++
>  7 files changed, 292 insertions(+), 4 deletions(-)
>  create mode 100644 arch/arm64/kvm/hyp/nvhe/translate.c
>  create mode 100644 tools/testing/selftests/kvm/arm64/translate.c

Oliver already gave a review of some aspects of the code. In short,
you're going about walking the page tables the wrong way, both by
ignoring some of the complicated architectural features (PIE, POE),
trusting the S1 PTs to be vaguely correct, and by assuming that S1 PTs
are never swapped out.

But there is more: you are assuming that the only translation regime
we care about is EL1&0, which isn't true. This would also need to
cater for EL2 and EL2&0.

As Oliver also pointed out, all that infrastructure already exists in
the kernel, and is able to do the right thing, with full support of
the expected feature set as presented to the guest.

But at the end of the day, what do you need KVM_TRANSLATE for? This
interface is an absolute turd that is unable to represent the bare
minimum of the architecture (writable by whom? physical address in
which translation regime? what about S2 translations?), and is better
left in the "utter brain fart" category.

Finally, and assuming that you actually need something of the sort,
why do you expect that something in the kernel will be better than a
pure userspace implementation?

Thanks,

	M.

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