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: <20250619115132.GA20673@e133081.arm.com>
Date: Thu, 19 Jun 2025 12:51:32 +0100
From: Mikołaj Lenczewski <miko.lenczewski@....com>
To: Catalin Marinas <catalin.marinas@....com>
Cc: ryan.roberts@....com, yang@...amperecomputing.com, will@...nel.org,
	jean-philippe@...aro.org, robin.murphy@....com, joro@...tes.org,
	maz@...nel.org, oliver.upton@...ux.dev, joey.gouly@....com,
	james.morse@....com, broonie@...nel.org, ardb@...nel.org,
	baohua@...nel.org, suzuki.poulose@....com, david@...hat.com,
	jgg@...pe.ca, nicolinc@...dia.com, jsnitsel@...hat.com,
	mshavit@...gle.com, kevin.tian@...el.com,
	linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org,
	iommu@...ts.linux.dev
Subject: Re: [PATCH v7 2/4] arm64: Add BBM Level 2 cpu feature

On Thu, Jun 19, 2025 at 12:05:05PM +0100, Catalin Marinas wrote:
> On Tue, Jun 17, 2025 at 09:51:02AM +0000, Mikołaj Lenczewski wrote:
> > diff --git a/arch/arm64/kernel/cpufeature.c b/arch/arm64/kernel/cpufeature.c
> > index f9c947166322..2e80ff237b96 100644
> > --- a/arch/arm64/kernel/cpufeature.c
> > +++ b/arch/arm64/kernel/cpufeature.c
> > @@ -2213,6 +2213,41 @@ static bool hvhe_possible(const struct arm64_cpu_capabilities *entry,
> >  	return arm64_test_sw_feature_override(ARM64_SW_FEATURE_OVERRIDE_HVHE);
> >  }
> >  
> > +static bool has_bbml2_noabort(const struct arm64_cpu_capabilities *caps, int scope)
> > +{
> > +	/*
> > +	 * We want to allow usage of BBML2 in as wide a range of kernel contexts
> > +	 * as possible. This list is therefore an allow-list of known-good
> > +	 * implementations that both support BBML2 and additionally, fulfill the
> > +	 * extra constraint of never generating TLB conflict aborts when using
> > +	 * the relaxed BBML2 semantics (such aborts make use of BBML2 in certain
> > +	 * kernel contexts difficult to prove safe against recursive aborts).
> > +	 *
> > +	 * Note that implementations can only be considered "known-good" if their
> > +	 * implementors attest to the fact that the implementation never raises
> > +	 * TLBI conflict aborts for BBML2 mapping granularity changes.
> 
> s/TLBI/TLB/
> 

ACK

> > +	 */
> > +	static const struct midr_range supports_bbml2_noabort_list[] = {
> > +		MIDR_REV_RANGE(MIDR_CORTEX_X4, 0, 3, 0xf),
> > +		MIDR_REV_RANGE(MIDR_NEOVERSE_V3, 0, 2, 0xf),
> > +		{}
> > +	};
> > +
> > +	/* Does our cpu guarantee to never raise TLB conflict aborts? */
> > +	if (!is_midr_in_range_list(supports_bbml2_noabort_list))
> > +		return false;
> > +
> > +	/*
> > +	 * We currently ignore the AA64_ID_MMFR2 register, and only care about
> 
> s/AA64_ID_MMFR2/ID_AA64MMFR2_EL1/
> 

ACK

> > +	 * whether the MIDR check passes. This is because we specifically
> > +	 * care only about a stricter form of BBML2 (one guaranteeing noabort),
> > +	 * and so the MMFR2 check is pointless (all implementations passing the
> > +	 * MIDR check should also pass the MMFR2 check).
> 
> I think there's at least one implementation that behaves as
> BBML2-noabort but does not have the ID field advertising BBML2.
> 

Yes, I put "should" instead of "will" because of the AmpereOne
situation, but I didn't want to "name and shame". Should I explicitly
call this out? Or would you like me to soften the vocabulary here to imply
that as long as the MIDR passes, the MMFR2 check is not important?

> > +	 */
> > +
> > +	return true;
> > +}
> > +
> >  #ifdef CONFIG_ARM64_PAN
> >  static void cpu_enable_pan(const struct arm64_cpu_capabilities *__unused)
> >  {
> > @@ -2980,6 +3015,11 @@ static const struct arm64_cpu_capabilities arm64_features[] = {
> >  		.matches = has_cpuid_feature,
> >  		ARM64_CPUID_FIELDS(ID_AA64MMFR2_EL1, EVT, IMP)
> >  	},
> > +	{
> > +		.capability = ARM64_HAS_BBML2_NOABORT,
> > +		.type = ARM64_CPUCAP_EARLY_LOCAL_CPU_FEATURE,
> > +		.matches = has_bbml2_noabort,
> > +	},
> >  	{
> >  		.desc = "52-bit Virtual Addressing for KVM (LPA2)",
> >  		.capability = ARM64_HAS_LPA2,
> > diff --git a/arch/arm64/tools/cpucaps b/arch/arm64/tools/cpucaps
> > index 10effd4cff6b..2bd2bfaeddcd 100644
> > --- a/arch/arm64/tools/cpucaps
> > +++ b/arch/arm64/tools/cpucaps
> > @@ -45,6 +45,7 @@ HAS_LPA2
> >  HAS_LSE_ATOMICS
> >  HAS_MOPS
> >  HAS_NESTED_VIRT
> > +HAS_BBML2_NOABORT
> >  HAS_PAN
> >  HAS_PMUV3
> >  HAS_S1PIE
> 
> Otherwise it looks fine.
> 
> Reviewed-by: Catalin Marinas <catalin.marinas@....com>

-- 
Kind regards,
Mikołaj Lenczewski

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ