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: <aD8oxsyuvLre2pY+@lpieralisi>
Date: Tue, 3 Jun 2025 18:54:30 +0200
From: Lorenzo Pieralisi <lpieralisi@...nel.org>
To: Peter Maydell <peter.maydell@...aro.org>
Cc: Rob Herring <robh@...nel.org>, Krzysztof Kozlowski <krzk+dt@...nel.org>,
	Marc Zyngier <maz@...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 Tue, Jun 03, 2025 at 05:04:33PM +0100, Peter Maydell wrote:
> On Tue, 3 Jun 2025 at 16:53, Lorenzo Pieralisi <lpieralisi@...nel.org> wrote:
> > Specifically, for IRS/ITS frames then - what the current schema does is
> > correct, namely, it does _not_ spell out whether the IRS/ITS config
> > frame is NS/S/Realm/Root interrupt domain, that's information that the
> > client implicitly assumes.
> >
> > Are we OK with this approach ? This would leave open the possibility
> > of having a DT per security-state.
> >
> > If in the DT schema I define eg reg -> "IRS NS config frame" by
> > construction the binding can't be used for anything else.
> >
> > Please let me know if we are in agreement on this matter.
> 
> This would break the QEMU virt board -> EL3 guest firmware ->
> EL1 Linux flow. We need a binding which lets us optionally
> specify "oh by the way here is where the other non-NS frames are".

Do we "need" a binding ? Or, it is a nice-have to help configure
QEmu (and other SW components, eg bootwrapper/TF-A, etc that decided
to re-use DT for their own consumption) ?

And even so, why can't we have a DT per security state as-per Rob's
reply ?

Given that only the "status" property is tagged with secure- today,
may I ask please how does this work ?

What's "EL3 guest firmware" ? Does it use the secure-status property to
detect that the respective device is secure/non-secure ?

And why does it have to be the same dtb we are passing to the OS client ?

> I don't have a strong view on the specific syntax.

I do because I don't want to revisit this later ;-)

Thanks,
Lorenzo