linux-kernel - Re: [PATCH v3 2/2] arm64/sysreg: Convert HFGITR

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]

Date:   Thu, 6 Apr 2023 16:02:18 +0100
From:   Mark Brown <broonie@...nel.org>
To:     Will Deacon <will@...nel.org>
Cc:     Catalin Marinas <catalin.marinas@....com>,
        Joey Gouly <joey.gouly@....com>,
        Anshuman Khandual <anshuman.khandual@....com>,
        linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v3 2/2] arm64/sysreg: Convert HFGITR_EL2 to automatic
 generation

On Thu, Apr 06, 2023 at 03:46:54PM +0100, Will Deacon wrote:
> On Thu, Mar 23, 2023 at 08:44:54PM +0000, Mark Brown wrote:

> > Automatically generate the Hypervisor Fine-Grained Instruction Trap
> > Register as per DDI0601 2022-12, currently we only have a definition for
> > the register name not any of the contents.  No functional change.

> > +Res0	63:61
> > +Field	60	COSPRCTX
> > +Field	59	nGCSEPP
> > +Field	58	nGCSSTR_EL1
> > +Field	57	nGCSPUSHM_EL1

> These aren't in the Arm ARM afaict ^^^

Yes, as mentioned in the cover letter these are as per DDI0601 2022-12,
the current at time of posting the patch latest release of the
architecture XML.  They should appear in the next release of the ARM,
the XML is updated more frequently.  The XML can be seen on the web
here:

    https://developer.arm.com/documentation/ddi0601/2022-12/AArch64-Registers/HFGITR-EL2--Hypervisor-Fine-Grained-Instruction-Trap-Register?lang=en

> Can't we generate this file from the architecture xml? That would hopefully
> avoid typos like this and make review less tedious.

I agree that this seems like a sensible idea however there has
previously been pushback on the idea of providing tooling to do that,
and we would want to manually integrate the output of any such tool
since there are a number of cases where for legacy or usability reasons
we rename or combine fields.  The cases where we use a Fields block to
cover identical ELx versions are another issue.

I also note that while the XML is viewable on the web AFAICT the only
directly downloadable version of the architecture XML available
externally is in PDF format which is not entirely helpful for this
purpose.

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