linux-kernel - Re: [PATCH v4 01/26] dt-bindings: interrupt-controller: Add Arm GICv5

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: <CAFEAcA_3YLMSy+OsSsRayaRciQ1+jjh-dGzEjrh2Wa8BqdmqrA@mail.gmail.com>
Date: Thu, 29 May 2025 14:17:26 +0100
From: Peter Maydell <peter.maydell@...aro.org>
To: Lorenzo Pieralisi <lpieralisi@...nel.org>
Cc: Marc Zyngier <maz@...nel.org>, Thomas Gleixner <tglx@...utronix.de>, Rob Herring <robh@...nel.org>, 
	Krzysztof Kozlowski <krzk+dt@...nel.org>, Conor Dooley <conor+dt@...nel.org>, 
	Catalin Marinas <catalin.marinas@....com>, Will Deacon <will@...nel.org>, andre.przywara@....com, 
	Arnd Bergmann <arnd@...db.de>, Sascha Bischoff <sascha.bischoff@....com>, 
	Timothy Hayes <timothy.hayes@....com>, "Liam R. Howlett" <Liam.Howlett@...cle.com>, 
	Mark Rutland <mark.rutland@....com>, Jiri Slaby <jirislaby@...nel.org>, 
	linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org, 
	devicetree@...r.kernel.org
Subject: Re: [PATCH v4 01/26] dt-bindings: interrupt-controller: Add Arm GICv5

On Thu, 29 May 2025 at 13:44, Lorenzo Pieralisi <lpieralisi@...nel.org> wrote:
>
> [+Andre, Peter]
>
> On Tue, May 13, 2025 at 07:47:54PM +0200, Lorenzo Pieralisi wrote:
> > +      reg:
> > +        minItems: 1
> > +        items:
> > +          - description: IRS control frame
>
> I came across it while testing EL3 firmware, raising the topic for
> discussion.
>
> The IRS (and the ITS) has a config frame (need to patch the typo
> s/control/config, already done) per interrupt domain supported, that is,
> it can have up to 4 config frames:
>
> - EL3
> - Secure
> - Realm
> - Non-Secure
>
> The one described in this binding is the non-secure one.
>
> IIUC, everything described in the DT represents the non-secure address
> space.

The dt bindings do allow for describing Secure-world devices:
Documentation/devicetree/bindings/arm/secure.txt has the
details. We use this in QEMU so we can provide a DTB to
guest EL3 firmware that tells it where the hardware is
(and which EL3 can then pass on to an NS kernel). It would
be helpful for the GICv5 binding to be defined in a way that
we can do this for a GICv5 system too.

> Two questions:
>
> - I don't have to spell out the IRS/ITS config frame (and SETLPI, by
>   the way) as non-secure, since that's implicit, is that correct ?

Do you want the DT binding to handle the case of "CPU and GIC do not
implement EL3, and the only implemented security state is Secure"
without the kernel needing to do something different from "ditto ditto
but the only implemented security state is Nonsecure" ?
(Currently booting.html says you must be in NS, so we effectively
say we don't support booting on this particular unicorn :-)
But the secure.txt bindings envisage "kernel got booted in S",
mostly for the benefit of aarch32.)

> - How can the schema describe, if present, EL3, Secure and Realm frames ?

The tempting thing to do is to have regs[] list the frames
in some given order, but the spec makes them not simple
supersets, allowing all of:
 * NS
 * S
 * NS, S, EL3
 * NS, Realm, EL3
 * NS, Realm, S, EL3

secure.txt says:
# The general principle of the naming scheme for Secure world bindings
# is that any property that needs a different value in the Secure world
# can be supported by prefixing the property name with "secure-". So for
# instance "secure-foo" would override "foo".

So maybe we could have
 reg : the NS frame(s)
 secure-reg : the S frame(s)
 realm-reg : the Realm frame(s)
 root-reg : the EL3 frame(s)

??

thanks
-- PMM