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: <Z-ObUJQn2dGsgSsO@linux.dev>
Date: Tue, 25 Mar 2025 23:14:40 -0700
From: Oliver Upton <oliver.upton@...ux.dev>
To: "Emi Kisanuki (Fujitsu)" <fj0570is@...itsu.com>
Cc: 'Steven Price' <steven.price@....com>,
	"'kvm@...r.kernel.org'" <kvm@...r.kernel.org>,
	"'kvmarm@...ts.linux.dev'" <kvmarm@...ts.linux.dev>,
	'Catalin Marinas' <catalin.marinas@....com>,
	'Marc Zyngier' <maz@...nel.org>, 'Will Deacon' <will@...nel.org>,
	'James Morse' <james.morse@....com>,
	'Suzuki K Poulose' <suzuki.poulose@....com>,
	'Zenghui Yu' <yuzenghui@...wei.com>,
	"'linux-arm-kernel@...ts.infradead.org'" <linux-arm-kernel@...ts.infradead.org>,
	"'linux-kernel@...r.kernel.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'" <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>
Subject: Re: [PATCH v7 00/45] arm64: Support for Arm CCA in KVM

Hi Emi,

On Wed, Mar 26, 2025 at 02:14:35AM +0000, Emi Kisanuki (Fujitsu) wrote:
> Hi all,
> 
> I tested Linux-cca cca-host/v7 patch with our Internal simulator based on QEMU (with CCA and MPAM support).
> A panic occurred when starting Realm, but I don't think this is a problem with the cca-host/v7 patch.
> The location of the panic is [1].
> 
> [1]https://lore.kernel.org/linux-arm-kernel/20241030160317.2528209-4-joey.gouly@arm.com
> diff --git a/arch/arm64/kernel/cpuinfo.c b/arch/arm64/kernel/cpuinfo.c
> index 44718d0482b3..46ba30d42b9b 100644
> --- a/arch/arm64/kernel/cpuinfo.c
> +++ b/arch/arm64/kernel/cpuinfo.c
> @@ -478,6 +478,9 @@ static void __cpuinfo_store_cpu(struct cpuinfo_arm64 *info)
>  	if (id_aa64pfr0_32bit_el0(info->reg_id_aa64pfr0))
>  		__cpuinfo_store_cpu_32bit(&info->aarch32);
>  
> +	if (id_aa64pfr0_mpam(info->reg_id_aa64pfr0))
> +		info->reg_mpamidr = read_cpuid(MPAMIDR_EL1); /////// panic occurred here. 
> +
>  	cpuinfo_detect_icache_policy(info);
>  }
> 
> There was no problem with the cca-host/v5 patch (based on v6.12).
> This panic is caused by accessing MPAMIDR_EL1 when the chip supports MPAM.
> This functionality was enabled when the cca host patch base version was rebased from v6.12 to v6.13.
> 
> I am not familiar with TF-A, but I think this maybe a TF-A's bug.
> Because It seems TF-A sets MPAM3_EL3.TRAPLOWER to 0 during normal guest boot in manage_extensions_nonsecure_per_world function[2].
> However, TF-A does not set it to 0 during Realm guest boot in manage_extensions_secure_per_world function.
> Therefore, a trap occurs against EL3 (TF-A), and it is likely being processed as an invalid instruction (Undef).

Your instinct is correct that this is *not* a kernel bug. It is the
responsibility of the RMM to provide a consistent feature set to the
Realm.

Looks like this was addressed recently in TF-RMM by hiding FEAT_MPAM:

https://github.com/TF-RMM/tf-rmm/commit/7b0874403726d215c40054abfd5d8704049f8dac

Thanks,
Oliver

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ