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

[Tom Rini]

On Sat, Jul 04, 2026 at 06:46:50PM +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.
> >
> 
> Nothing wrong with the spec. Some hardware engineers simply don't read it and create watchdog timers that cannot be set to a 5 min timeout.

Maybe 5 minutes is acceptable in some use cases. It's certainly not in
others. The spec needs to be updated to reflect the reality of
industries that people are pushing to use UEFI in. And then operating
systems need to reflect that a watchdog is not some niche device for
arm64 but something virtually every platform has and that it must be
serviced ASAP.

-- 
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/c7b35815/attachment.sig>