linux-kernel - Re: [PATCH v10 05/43] arm64: RME: Check for RME support at KVM init

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <86h5wizqvn.wl-maz@kernel.org>
Date: Wed, 01 Oct 2025 14:35:40 +0100
From: Marc Zyngier <maz@...nel.org>
To: Steven Price <steven.price@....com>
Cc: kvm@...r.kernel.org,
	kvmarm@...ts.linux.dev,
	Catalin Marinas <catalin.marinas@....com>,
	Will Deacon <will@...nel.org>,
	James Morse <james.morse@....com>,
	Oliver Upton <oliver.upton@...ux.dev>,
	Suzuki K Poulose <suzuki.poulose@....com>,
	Zenghui Yu
 <yuzenghui@...wei.com>,
	linux-arm-kernel@...ts.infradead.org,
	linux-kernel@...r.kernel.org,
	Joey Gouly <joey.gouly@....com>,
	Alexandru Elisei <alexandru.elisei@....com>,
	Christoffer Dall <christoffer.dall@....com>,
	Fuad Tabba <tabba@...gle.com>,
	linux-coco@...ts.linux.dev,
	Ganapatrao Kulkarni <gankulkarni@...amperecomputing.com>,
	Gavin Shan <gshan@...hat.com>,
	Shanker Donthineni <sdonthineni@...dia.com>,
	Alper Gun <alpergun@...gle.com>,
	"Aneesh Kumar K . V"
 <aneesh.kumar@...nel.org>,
	Emi Kisanuki <fj0570is@...itsu.com>,
	Vishal Annapurve <vannapurve@...gle.com>
Subject: Re: [PATCH v10 05/43] arm64: RME: Check for RME support at KVM init

On Wed, 01 Oct 2025 14:20:13 +0100,
Steven Price <steven.price@....com> wrote:
> 
> >> +static int rmi_check_version(void)
> >> +{
> >> +	struct arm_smccc_res res;
> >> +	unsigned short version_major, version_minor;
> >> +	unsigned long host_version = RMI_ABI_VERSION(RMI_ABI_MAJOR_VERSION,
> >> +						     RMI_ABI_MINOR_VERSION);
> >> +
> >> +	arm_smccc_1_1_invoke(SMC_RMI_VERSION, host_version, &res);
> > 
> > Shouldn't you first check that RME is actually available, by looking
> > at ID_AA64PFR0_EL1.RME?
> 
> Well, you made a good point above that this isn't RME, it's CCA. And I
> guess there's a possible world where the CCA interface could be
> supported with something other than FEAT_RME (FEAT_RME2 maybe?) so I'm
> not sure it necessarily a good idea to pin this on a CPU feature
> bit.

But you cannot have CCA without RME. You cannot have CCA with
GICv3. And my point was more that RME could be used by something other
than CCA  - I certainly don't anticipate someone else adopting the CCA
interface for anything...

> Ultimately what we want to know is whether the firmware thinks it can
> supply us with the CCA interface and we don't really care how it
> achieves it.

I disagree. You rely on specific feature sets to be available (hell,
everything is baked around GICv3... GICv5 anyone?).

For this sort of stuff, you absolutely need to know what you are
running on, not what some broken firmware tries to pretend it is.

	M.

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