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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAFEAcA9xBJiRQ+UMvyOSOqOwMPYrjja0Vhk8j4_0V7f7_0ETtg@mail.gmail.com>
Date: Wed, 4 Jun 2025 21:09:27 +0100
From: Peter Maydell <peter.maydell@...aro.org>
To: Lorenzo Pieralisi <lpieralisi@...nel.org>
Cc: Marc Zyngier <maz@...nel.org>, Rob Herring <robh@...nel.org>, 
	Krzysztof Kozlowski <krzk+dt@...nel.org>, 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, 4 Jun 2025 at 17:35, Lorenzo Pieralisi <lpieralisi@...nel.org> wrote:
> Can I ask again what:
>
> status = "disabled"
> secure-status = "okay"
>
> for a device means in practice in the current bindings ?

>From software's point of view, it means "if you're NonSecure,
ignore this; if you're Secure, feel free to use it".
>From the point of view of something creating this DT node,
the usual reason for setting up a node like that is that the
device is only present in the Secure memory map, not the NS one;
so marking it that way lets you tell the S firmware where the
device is and also tell the NS kernel to ignore it so it doesn't
try to probe for the device and fall over when it gets an exception.

> 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.
secure.txt is careful to define the general principles of
how the naming scheme works but then to restrict it only to the
specific cases that we've blessed as OK. I think that's worked
pretty well -- it's fitted the needs we have and the GICv5 is
only the second time in a decade we've had to revisit and say
"we also want XYZ" (the first being /secure-chosen/stdout-path,
in 2018). I think that's a pretty decent track record. In
adding whatever we want to do for GICv5, I agree with Rob
that we don't want to accidentally open the door for more
general use of secure-reg or whatever on other random devices.

thanks
-- PMM