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

[Carlo Caione]

> 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.

Cheers,

—
Carlo Caione