linux-kernel - Re: [PATCH 2/2] KVM: selftests: arm64: Use generated defines for named system registers

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: <6c1beda4-7211-4f64-95c8-7a11c489b145@sirena.org.uk>
Date: Mon, 5 Aug 2024 17:16:43 +0100
From: Mark Brown <broonie@...nel.org>
To: Marc Zyngier <maz@...nel.org>
Cc: Oliver Upton <oliver.upton@...ux.dev>,
	James Morse <james.morse@....com>,
	Suzuki K Poulose <suzuki.poulose@....com>,
	Paolo Bonzini <pbonzini@...hat.com>, Shuah Khan <shuah@...nel.org>,
	Catalin Marinas <catalin.marinas@....com>,
	Joey Gouly <joey.gouly@....com>,
	linux-arm-kernel@...ts.infradead.org, kvmarm@...ts.linux.dev,
	kvm@...r.kernel.org, linux-kselftest@...r.kernel.org,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH 2/2] KVM: selftests: arm64: Use generated defines for
 named system registers

On Sat, Aug 03, 2024 at 10:35:54AM +0100, Marc Zyngier wrote:
> Mark Brown <broonie@...nel.org> wrote:

> > This conversion was done with the sed command:

> >   sed -i -E 's-ARM64_SYS_REG.*/\* (.*) \*/-KVM_ARM64_SYS_REG(SYS_\1),-' tools/testing/selftests/kvm/aarch64/get-reg-list.c

> [Eyes rolling]

> What I asked about scripting the whole thing, it never occurred to me
> that you would use the *comments* as a reliable source of information.
> Do we have anything less reliable than comments in the kernel?

I think we should ultimately be using both the comments and the
encodings - the comments indicate what people thought was being tested
and it's useful to make sure we have that coverage even if the
implementation were to have been wrong.

Doing this step is also going to have picked up registers which we don't
yet have in the sysreg file, some of which are going to be painful to
add there (things like ESR for example) so aren't likely to get done in
a hurry due to complexity in their definitions.

This was quick to do, represents progress, and offers a hint to anyone
adding new registers that they should use the symbolic definitions.

> The matching must be done from the arch/arm64/tools/sysreg file,
> because that's the (admittedly dubious) source of truth. We actually
> trust the encodings because they are reported by the kernel itself.
> The comment is hand-written, and likely wrong.

Sure, there's a reason I compared the resulting binaries rather than
just trusting that the conversion gave the same result.

> > -	ARM64_SYS_REG(3, 3, 14, 3, 1),	/* CNTV_CTL_EL0 */
> > -	ARM64_SYS_REG(3, 3, 14, 3, 2),	/* CNTV_CVAL_EL0 */
> > +	KVM_ARM64_SYS_REG(SYS_CNTV_CTL_EL0),
> > +	KVM_ARM64_SYS_REG(SYS_CNTV_CVAL_EL0),
> >  	ARM64_SYS_REG(3, 3, 14, 0, 2),

> Great. So not only you fail convert a register, but you also ignore
> the nugget described in arch/arm64/invlude/uapi/asm/kvm.h:267.

That's that CNTV_CTL_EL0 and CNTV_CVAL_EL0 have their encodings
reversed in the ABI.

> Sure, having both described hides the crap, as we don't attach any
> significance to the registers themselves. But that shows how
> untrustworthy the comments are.

I'm afraid that any automated conversion is likely to trip over an ABI
issue like that - the obvious thing to do when looking up by encoding
would be to just emit a KVM_ARM64_SYS_REG() if we find the encoding
which would give the same end result.  I'll add a separate manual update
of these registers.

Are there any other similar issues?  I didn't spot anything in kvm.h.

> >  	ARM64_SYS_REG(2, 0, 0, 0, 4),
> >  	ARM64_SYS_REG(2, 0, 0, 0, 5),
> >  	ARM64_SYS_REG(2, 0, 0, 0, 6),

> As far as I can tell, these registers are not unallocated, and they
> should be named.

I agree that we should do all named registers eventually, the above are
numbered debug registers (DBGBVR0_EL1, DBGBCR0_EL1 and DBGWVR0_EL1)
which aren't in the sysreg file yet so wouldn't currently be covered by
a conversion based on pulling encodings from there.  They could also be
done immediately with a generator script as there are DBGBVRn_EL1 style
macros there.

Like I say this is a quick first step and does improve things, there's
still more to do but I do think this moves us forward.  We can and
should come back later and build on things as people have time.

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