linux-kernel - Re: [PATCH v13 07/10] firmware: psci: Implement vendor-specific resets as reboot-mode

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: <afa34f49d502d7f921818141979167920b8d924a.camel@linaro.org>
Date: Thu, 31 Jul 2025 11:25:25 +0100
From: André Draszik <andre.draszik@...aro.org>
To: Shivendra Pratap <shivendra.pratap@....qualcomm.com>, Bartosz
 Golaszewski	 <bartosz.golaszewski@...aro.org>, Bjorn Andersson
 <andersson@...nel.org>,  Sebastian Reichel	 <sre@...nel.org>, Rob Herring
 <robh@...nel.org>, Sudeep Holla	 <sudeep.holla@....com>, Souvik Chakravarty
 <Souvik.Chakravarty@....com>,  Krzysztof Kozlowski	 <krzk+dt@...nel.org>,
 Conor Dooley <conor+dt@...nel.org>, Andy Yan	 <andy.yan@...k-chips.com>,
 Mark Rutland <mark.rutland@....com>, Lorenzo Pieralisi
 <lpieralisi@...nel.org>, Arnd Bergmann <arnd@...db.de>, Konrad Dybcio
 <konradybcio@...nel.org>, 	cros-qcom-dts-watchers@...omium.org, Vinod Koul
 <vkoul@...nel.org>, Catalin Marinas <catalin.marinas@....com>, Will Deacon
 <will@...nel.org>, Florian Fainelli	 <florian.fainelli@...adcom.com>
Cc: Dmitry Baryshkov <dmitry.baryshkov@....qualcomm.com>, Mukesh Ojha
	 <mukesh.ojha@....qualcomm.com>, Stephen Boyd <swboyd@...omium.org>, 
	linux-pm@...r.kernel.org, linux-kernel@...r.kernel.org, 
	devicetree@...r.kernel.org, linux-arm-kernel@...ts.infradead.org, 
	linux-arm-msm@...r.kernel.org, Elliot Berman <quic_eberman@...cinc.com>, 
 Srinivas Kandagatla
	 <srini@...nel.org>
Subject: Re: [PATCH v13 07/10] firmware: psci: Implement vendor-specific
 resets as reboot-mode

On Thu, 2025-07-31 at 11:05 +0530, Shivendra Pratap wrote:
> 
> 
> On 7/30/2025 8:53 PM, André Draszik wrote:
> > More importantly, if e.g. an OOPS / panic happens after the reboot
> > notifier has run (and set vendor_reset.valid because a reboot mode
> > was requested), a panic handler changing reboot_mode to warm to
> > retain RAM contents will have no effect, because the the original
> > code above making those distinctions can not be reached anymore.
> > 
> > Above scenario with OOPS / panic after reboot notifier could e.g.
> > happen as part of device_shutdown() - see kernel_shutdown_prepare()
> 
> We can handle the panic path by adding a panic_notifier in psci
> and make vendor_reset.valid = false. Do you think adding this can clear
> the panic scenario above or there can still be some leak?

I think that would work. You then can't convey the reboot command, but
at that stage (panic/oops) it probably doesn't matter anymore, it only
cares about the crash handling which probably is enough.

Cheers,
Andre'