linux-kernel - Re: [PATCH v2 0/4] A new selftests/ directory for arm compatibility testing

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] [day] [month] [year] [list]

Message-ID: <Ziho0Pl7JQ8m4Uh4@finisterre.sirena.org.uk>
Date: Wed, 24 Apr 2024 11:05:04 +0900
From: Mark Brown <broonie@...nel.org>
To: Muhammad Usama Anjum <usama.anjum@...labora.com>
Cc: Will Deacon <will@...nel.org>, Dev Jain <dev.jain@....com>,
	shuah@...nel.org, linux-arm-kernel@...ts.infradead.org,
	linux-kselftest@...r.kernel.org, linux-kernel@...r.kernel.org,
	Anshuman.Khandual@....com, suzuki.poulose@....com,
	ryan.roberts@....com, rob.herring@....com, Catalin.Marinas@....com,
	mark.rutland@....com, linux@...linux.org.uk
Subject: Re: [PATCH v2 0/4] A new selftests/ directory for arm compatibility
 testing

On Tue, Apr 23, 2024 at 01:55:07PM +0500, Muhammad Usama Anjum wrote:
> On 4/22/24 10:21 PM, Will Deacon wrote:

> > Isn't this going to be difficult to maintain if we have two divergent copies
> > of the same stuff? From a very quick skim, a bunch of the signals stuff is
> > idential to what we have on arm64...

> Agreed.

> Why don't we follow what x86 suite has been doing? Compile tests for both
> arm and arm64, and add conditionals in the tests based on architecture.

> If someone has objection that the suite name is arm64, just rename it to
> arm which would be a generic name.

Given that we haven't done that for any other arm/arm64 stuff I suspect
that specific approach would lead to some combination of confusion and
people just plain missing the fact that the 32 bit tests are there.
It's just not the idiom that's been used for handling things elsewhere
so it feels like asking for people to make mistakes.  With the signal
tests (which seem like the only bit that's really shared here) it's
mostly just some of the library code that we want to duplicate, the
actual test set for 32 bit will be different.

What some of the other testsuites do to pull in other tests as libraries
is to just reference the source files (KVM does this with rseq IIRC).
We could do that here and try to refactor the framework code for the
signal tests so that it can be built for both 64 and 32 bit, then have
the 32 bit Makefile pull in the shared code from the 64 bit directory.
I'm not sure if it's worth the effort or not - there is some obvious
duplication but a good chunk of the arm64 code is feature detection and
handling of the extensible signal context neither of which apply for 32
bit.

If we are pulling stuff out it might even make sense to have something
that other non-arm architectures can use since I'm not sure how much of
the framework code that can be shared is even arm specific.

Download attachment "signature.asc" of type "application/pgp-signature" (489 bytes)