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

Message-ID: <aEFP+wsYCmMgIyhs@lpieralisi>
Date: Thu, 5 Jun 2025 10:06:19 +0200
From: Lorenzo Pieralisi <lpieralisi@...nel.org>
To: Peter Maydell <peter.maydell@...aro.org>, Rob Herring <robh@...nel.org>,
	Krzysztof Kozlowski <krzk+dt@...nel.org>,
	Marc Zyngier <maz@...nel.org>
Cc: Thomas Gleixner <tglx@...utronix.de>,
	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, suzuki.poulose@....com
Subject: Re: [PATCH v4 01/26] dt-bindings: interrupt-controller: Add Arm GICv5

On Wed, Jun 04, 2025 at 09:09:27PM +0100, Peter Maydell wrote:

[...]

> > When I said "a separate problem", I meant that, extending secure- tag
> > (that applies to the "status" property only) to cover other PASes is
> > independent from the GICv5 binding *if* we define, for a single DT an eg
> > IRS device per-PAS (with realm-status, root-status, describing what the
> > reg property represents. Is that what secure-status does today ? Does
> > it say "this device MMIO space is secure-only" ?).
> >
> > It does not look like there is much appetite for tagging the reg
> > property either and making it GICv5 specific is a shortcut IMO.
> 
> I think something GICv5 specific is not unreasonable.

We need to define up to 4 interrupt domains (so max 4 frames per
component per frame type: EL3, Secure, Realm, Non-Secure).

Options:

1) Using reg and reg-names, I don't know if reg-names allows us to
   describe all possible resource names and the order does not matter,
   please let me know. Keep in mind that some resources are optional.

   Something like, for an IRS:

   reg-names = "el3-config", "secure-config", "realm-config",
   "non-secure-config", "el3-setlpi", "secure-setlpi", "realm-setlpi",
   "non-secure-setlpi";

   With that, I would remove the description in the reg property and
   just say minItems: 1

   This implicitly means that describing in DT a resource that the
   CPU possibly is not able to reach depending on
   security-state/exception level is OK. AFAICS reg-names achieves
   the same purpose of tagging below, at the end of the day it is
   a means to say eg "if you are non-secure stay away from something
   that does not belong to you".

2) We add a tagged "reg" property for GICv5 ("reg" refers to non-secure):

   reg
   el3-reg
   secure-reg
   realm-reg

3) We add a GICv5 tagged "status" property and define an eg IRS device per
   interrupt-domain ("status" refers to non-secure):

   status
   el3-status
   secure-status
   realm-status

4) Anything else that I have not thought of

What's the best option ? Please let me know, I'd like to repost the
series at v6.16-rc1 with a solution.

Thanks,
Lorenzo