linux-kernel - Re: [GICv3 ITS]S2IDLE framework does not invoke syscore

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: <20250408222851.GB2187207@tiffany>
Date: Wed, 9 Apr 2025 07:28:51 +0900
From: Donghyeok Choe <d7271.choe@...sung.com>
To: Marc Zyngier <maz@...nel.org>
Cc: Youngmin Nam <youngmin.nam@...sung.com>, Sudeep Holla
	<sudeep.holla@....com>, Thomas Gleixner <tglx@...utronix.de>, Saravana
	Kannan <saravanak@...gle.com>, Ulf Hansson <ulf.hansson@...aro.org>, Vincent
	Guittot <vincent.guittot@...aro.org>, linux-arm-kernel@...ts.infradead.org,
	linux-kernel@...r.kernel.org, kernel-team@...roid.com,
	hajun.sung@...sung.com, joonki.min@...sung.com, ne.yoo@...sung.com,
	Donghyeok Choe <d7271.choe@...sung.com>
Subject: Re: [GICv3 ITS]S2IDLE framework does not invoke syscore_ops in
 GICv3 ITS driver

On Tue, Apr 08, 2025 at 07:51:32AM +0100, Marc Zyngier wrote:
> On Mon, 07 Apr 2025 23:51:46 +0100,
> Donghyeok Choe <d7271.choe@...sung.com> wrote:
> > 
> > [1  <text/plain; us-ascii (7bit)>]
> > On Mon, Apr 07, 2025 at 10:17:43AM +0100, Sudeep Holla wrote:
> 
> > > Do you use any suspend/resume logic in drivers/irqchip/irq-gic-pm.c ?
> > No, there are parts of the GIC that require secure access, so the
> > GIC save/restore is performed by the firmware.
> > Since the GIC-ITS is entirely controlled as a non-secure IP,
> > I think it is more efficient to perform save/restore in the kernel.
> 
> More efficient? Give me *one* aspect of this save/restore sequence
> that is done in a more efficiently way in the kernel. Dumping MMIO
> accesses into memory has the exact same cost at EL1, El2 or EL3, and
> splitting things along an arbitrary line to paper over bad firmware is
> not a valid argument.

If I had to highlight just one efficiency gain — it's that I get to
reuse well-tested and well-written save/restore code without
reinventing the wheel (or worse, reinventing a square one).
And as for bad firmware... I guess it deserves the punishment
of handling GIC ITS save/restore.

That said, I truly appreciate your insight, and I’ll make an effort
to avoid relying on such suboptimal kernel usage going forward.

Best regards,  
Donghyeok Choe