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: <3wesm6syeqmjdzyyj2mjp4sjfwl7ebeahqxwcvub6gwvoifuh4@43tunmtjsq4h>
Date: Thu, 3 Jul 2025 08:55:31 +0200
From: Thierry Reding <thierry.reding@...il.com>
To: Kartik Rajput <kkartik@...dia.com>
Cc: daniel.lezcano@...aro.org, tglx@...utronix.de, jonathanh@...dia.com, 
	linux-kernel@...r.kernel.org, linux-tegra@...r.kernel.org
Subject: Re: [PATCH] clocksource: timer-tegra186: Enable WDT at probe

On Mon, Jun 30, 2025 at 04:31:35PM +0530, Kartik Rajput wrote:
> Currently, if the system crashes or hangs during kernel boot before
> userspace initializes and configures the watchdog timer, then the
> watchdog won’t be able to recover the system as it’s not running. This
> becomes crucial during an over-the-air update, where if the newly
> updated kernel crashes on boot, the watchdog is needed to reset the
> device and boot into an alternative system partition. If the watchdog
> is disabled in such scenarios, it can lead to the system getting
> bricked.
> 
> Enable the WDT during driver probe to allow recovery from any crash/hang
> seen during early kernel boot. Also, disable interrupts once userspace
> starts pinging the watchdog.
> 
> Signed-off-by: Kartik Rajput <kkartik@...dia.com>
> ---
>  drivers/clocksource/timer-tegra186.c | 42 ++++++++++++++++++++++++++++
>  1 file changed, 42 insertions(+)

This seems dangerous to me. It means that if the operating system
doesn't start some sort of watchdog service in userspace that pings the
watchdog, the system will reboot 120 seconds after the watchdog probe.

I think the convention is to enable the watchdog only via userspace
request, precisely to avoid this kind of unexpected behavior.

If we really want this, maybe a better solution would be to add one more
watchdog that is specifically kernel-controlled? We have 3 watchdog
instances on all these newer chips but currently only use one of them,
so grabbing another that is then entirely under the control of the
kernel should work for these cases.

Thierry

Download attachment "signature.asc" of type "application/pgp-signature" (834 bytes)

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ