linux-kernel - Re: [PATCH v3 2/9] arm64/sysreg: Update ID_AA64ISAR3

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: <20241211224015.GB17836@willie-the-truck>
Date: Wed, 11 Dec 2024 22:40:15 +0000
From: Will Deacon <will@...nel.org>
To: Mark Brown <broonie@...nel.org>
Cc: Catalin Marinas <catalin.marinas@....com>,
	Jonathan Corbet <corbet@....net>, Marc Zyngier <maz@...nel.org>,
	Oliver Upton <oliver.upton@...ux.dev>,
	Joey Gouly <joey.gouly@....com>,
	Suzuki K Poulose <suzuki.poulose@....com>,
	Shuah Khan <shuah@...nel.org>, linux-arm-kernel@...ts.infradead.org,
	linux-kernel@...r.kernel.org, linux-doc@...r.kernel.org,
	kvmarm@...ts.linux.dev, linux-kselftest@...r.kernel.org
Subject: Re: [PATCH v3 2/9] arm64/sysreg: Update ID_AA64ISAR3_EL1 to DDI0601
 2024-09

On Tue, Dec 10, 2024 at 06:43:05PM +0000, Mark Brown wrote:
> On Tue, Dec 10, 2024 at 05:09:55PM +0000, Will Deacon wrote:
> 
> > Can we _please_ just generate this stuff. It feels like we've been
> > making silly typos over and over again with the current approach so
> > either it's hard or we're not very good at it. Either way, it should be
> > automated.
> 
> > Others have managed it [1], so it's clearly do-able.
> 
> Yes, the issues here are not technical ones.  Though there are some
> complications -  eg, IIRC the XML doesn't encode the signedness of
> fields like we do and there's areas where we've deliberately diverged.
> Given the amount of review I end up having to do of sysreg changes your
> reasoning is especially apparent to me.  I've passed this feedback on
> (again).

One thing we _could_ do is have a tool (in-tree) that takes two copies
of the sysreg file (i.e. before and after applying a diff) along with a
copy of the XML and, for the the new fields being added, shows how the
XML represents those compared to the diff. It should then be relatively
straightforward to flag the use of an unallocated encoding (like we had
here) and also things like assigning a field name to a RES0 region.

So this wouldn't be generating the patches from the XML, but more like
using the XML as an oracle in a linter.

Will