[PATCH] efi_loader: stop watchdog devices in ExitBootServices()

[Tom Rini]

On Sat, Jul 04, 2026 at 06:59:08PM +0200, Heinrich Schuchardt wrote:
> Am 4. Juli 2026 18:17:07 MESZ schrieb Tom Rini <trini at konsulko.com>:
> >On Sat, Jul 04, 2026 at 05:21:25PM +0200, Carlo Caione wrote:
> >> 
> >> 
> >> > On 4 Jul 2026, at 16:32, Tom Rini <trini at konsulko.com> wrote:
> >> > 
> >> > On Sat, Jul 04, 2026 at 03:52:29PM +0200, Carlo Caione wrote:
> >> > 
> >> >> U-Boot can autonomously start a hardware watchdog
> >> >> (CONFIG_WATCHDOG_AUTOSTART, default y) and service it from its main
> >> >> loop, but the EFI boot path never stops it: efi_exit_boot_services()
> >> >> tears the devices down without calling wdt_stop_all(), and a watchdog
> >> >> driver without a .remove hook leaves the hardware ticking across the
> >> >> firmware-to-OS handoff.
> >> >> 
> >> >> An EFI-booted OS that does not take over the SoC watchdog within the
> >> >> remaining timeout is reset mid-boot at a wall-clock-dependent point.
> >> >> 
> >> >> The UEFI specification (v2.11, section 7.5 "Miscellaneous Boot
> >> >> Services", EFI_BOOT_SERVICES.SetWatchdogTimer()) is explicit about the
> >> >> one watchdog it allows across the handoff:
> >> >> 
> >> >>  "The watchdog timer is only used during boot services. On
> >> >>   successful completion of EFI_BOOT_SERVICES.ExitBootServices() the
> >> >>   watchdog timer is disabled."
> >> >> 
> >> >> U-Boot's UEFI watchdog (an EFI timer event) complies by construction. A
> >> >> platform watchdog silently surviving the handoff defeats the purpose of
> >> >> that rule: the OS has no generic way to know it is running, let alone to
> >> >> service it.
> >> >> 
> >> >> Stop all watchdog devices in efi_exit_boot_services(), before the device
> >> >> teardown.
> >> >> 
> >> >> Signed-off-by: Carlo Caione <ccaione at baylibre.com>
> >> > 
> >> > NAK. We have had this come up before, and in short, the UEFI
> >> > specification needs to be fixed here, as generally speaking a watchdog
> >> > should never be stopped, as that leaves a gap where the system can hang
> >> > and thus defeat the point of having enabled a watchdog.
> >> 
> >> 
> >> Fair enough.
> >> 
> >> For the record, the failure that motivated this: a pristine Ubuntu 26.04 arm64 image on a MediaTek Genio 700 EVK dies silently about 60 seconds after ExitBootServices(), 100% reproducible, at a wall-clock dependent point. The generic kernel ships the watchdog driver as a module, so nothing services the watchdog in time, and nothing tells the OS that it is running. From the user's side this is indistinguishable from broken firmware.
> >> 
> >> In the meantime, is the accepted pattern hooking up a wdt_stop_all() in the EFI path via board_quiesce_devices()? That keeps the watchdog armed for the whole firmware lifetime and makes the handoff behaviour the board maintainer's call.
> >
> >No, Ubuntu needs to fix their kernel image to have the watchdog
> >available early. I hate to be difficult on this, but it's been a known
> >issue for years at this point that the spec needs to be updated. The
> >workaround here is for the watchdog to not be started until the OS is
> >ready to maintain it.
> >
> 
> Best open a Launchpad bug explaining why this watchdog driver needs to be built in and not a module.

I'll leave that to Carlos, and I would suggest digging out the mailing
list threads from a year or two (or three?) ago when this had come up
before, and the problem was explained and it was spelled out that U-Boot
will not be spec compliant here, and I thought someone even volunteered
to take this to the spec to get updated.

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 228 bytes
Desc: not available
URL: <https://lists.denx.de/pipermail/u-boot/attachments/20260704/f7097e87/attachment.sig>