linux-kernel - Re: [PATCH v5 6/7] kselftest/arm64/mte: preparation for mte store only test

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: <aEmOzrU3bZEbLcWK@e129823.arm.com>
Date: Wed, 11 Jun 2025 15:12:30 +0100
From: Yeoreum Yun <yeoreum.yun@....com>
To: Mark Brown <broonie@...nel.org>
Cc: catalin.marinas@....com, pcc@...gle.com, will@...nel.org,
	anshuman.khandual@....com, joey.gouly@....com, maz@...nel.org,
	oliver.upton@...ux.dev, frederic@...nel.org,
	hardevsinh.palaniya@...iconsignals.io, samuel.holland@...ive.com,
	palmer@...osinc.com, charlie@...osinc.com,
	thiago.bauermann@...aro.org, bgray@...ux.ibm.com,
	tglx@...utronix.de, puranjay@...nel.org, david@...hat.com,
	yang@...amperecomputing.com, mbenes@...e.cz,
	joel.granados@...nel.org, linux-arm-kernel@...ts.infradead.org,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH v5 6/7] kselftest/arm64/mte: preparation for mte store
 only test

Hi Mark,

> On Wed, Jun 11, 2025 at 10:48:01AM +0100, Yeoreum Yun wrote:
> > Since ARMv8.9, FEAT_MTE_STORE_ONLY can be used to restrict raise of tag
> > check fault on store operation only.
> >
> > This patch is preparation for testing FEAT_MTE_STORE_ONLY
> > It shouldn't change test result.
>
> Not verified that that's the case but from inspection:
>
> Reviewed-by: Mark Brown <broonie@...nel.org>

Thanks ;)

> > -	mte_switch_mode(mode, MTE_ALLOW_NON_ZERO_TAG);
> > +	mte_switch_mode(mode, MTE_ALLOW_NON_ZERO_TAG, false);
> >  	item = ARRAY_SIZE(sizes);
>
> I was going to say on the other series that the boolean flags are kind
> of awkward from a readability point of view, but equally it doesn't feel
> worth it to make these arguments enums so I'll just mention it but it's
> fine either way.

Thanks. later I'll use enum first.

--
Sincerely,
Yeoreum Yun