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: <97759f51-385b-4ce4-8766-d00ed5af580b@amazon.com>
Date: Tue, 23 Sep 2025 10:39:07 +0200
From: Alexander Graf <graf@...zon.com>
To: Priscilla Lam <prl@...zon.com>, <maz@...nel.org>, <oliver.upton@...ux.dev>
CC: <christoffer.dall@....com>, <dwmw@...zon.co.uk>, <gurugubs@...zon.com>,
	<jgrall@...zon.co.uk>, <joey.gouly@....com>, <kvmarm@...ts.linux.dev>,
	<linux-arm-kernel@...ts.infradead.org>, <linux-kernel@...r.kernel.org>,
	<suzuki.poulose@....com>, <yuzenghui@...wei.com>
Subject: Re: [PATCH] KVM: arm64: Implement KVM_TRANSLATE ioctl for arm64

Hi Priscilla,

On 23.09.25 10:29, Priscilla Lam wrote:
> Hi Oliver and Marc,
>
> Thanks for the detailed feedback.
>
>> 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.
> Regarding motivation, this patch is intended to give a userspace vmm
> the ability to handle non-ISV guest faults. The Arm Arm (DDI 0487L.b,
> section B3.13.6) notes that for load/store pair faults, the syndrome
> may not provide the specifics of the access that faulted. In those
> cases, the vmm must manually decode the instruction to emulate it. The
> introduction of KVM_CAP_ARM_NISV_TO_USER
> (https://lore.kernel.org/kvm/20191120164236.29359-2-maz@kernel.org/)
> seems to have anticipated that flow by allowing exits to userspace on
> trapped NISV instructions. What is still missing is a reliable way for
> userspace to query VA->IPA translations in order to complete emulation.


All modern OSs constrain themselves to only ISV enabled MMIO 
instructions. NISV is really only useful to run non hypervisor 
enlightened guests. Did you encounter a real world OS that was causing 
NISV faults? And if so, what was causing these? It's most likely a 
driver or OS bug.

Alex




Amazon Web Services Development Center Germany GmbH
Tamara-Danz-Str. 13
10243 Berlin
Geschaeftsfuehrung: Christian Schlaeger
Eingetragen am Amtsgericht Charlottenburg unter HRB 257764 B
Sitz: Berlin
Ust-ID: DE 365 538 597