Why isn't the watchdog disabled by UEFI?

[Kristian Klausen]

Hi

This project is what I have been looking for (secure boot + watchdog),
but I have a hard time grasping why it works.

The UEFI spec states[1]:
"The watchdog timer is only used during boot services. On successful
completion of EFI_BOOT_SERVICES.ExitBootServices() the watchdog timer is
disabled."

So the boot looke something like this (AFAIU):
1. efibootguard starts
2. efibootguard initializes the watchdog
3. LoadImage()
4. StartImage()
5. Linux starts and calls ExitBootServices()

Why isn't UEFI disabling the watchdog initialized by efibootguard when
ExitBootServices() is called?

[1] UEFI Spec 2.6, EFI_BOOT_SERVICES.SetWatchdogTimer():

Best regards
Kristian Klausen

[Jan Kiszka]

Actually, this limitation of the UEFI-specified watchdog is one of the
reasons EFI Boot Guard exists. Here, we don't use the UEFI-provided
watchdog but real ones (including those described via WDAT, but those
are HW watchdogs as well). And those real watchdogs will not stop when
the boot services are terminated. Rather, Linux will pick them up and
continue to drive them.

Jan

--
Siemens AG, T RDA IOT
Corporate Competence Center Embedded Linux

[Kristian Klausen]

Thanks for the explanation, is the "UEFI-specified watchdog" not using
the hardware watchdog? or how is efibootguard preventing UEFI from
messing with the watchdog?

According to the spec UEFI will disable the watchdog when
ExitBootServices() is called. I assume that is still happening with
efibootguard?

Best regards
Kristian Klausen

[Christian Storm]

> > This project is what I have been looking for (secure boot + watchdog),
> > but I have a hard time grasping why it works.
> >
> > The UEFI spec states[1]:
> > "The watchdog timer is only used during boot services. On successful
> > completion of EFI_BOOT_SERVICES.ExitBootServices() the watchdog timer is
> > disabled."
> >
> > So the boot looke something like this (AFAIU):
> > 1. efibootguard starts
> > 2. efibootguard initializes the watchdog
> > 3. LoadImage()
> > 4. StartImage()
> > 5. Linux starts and calls ExitBootServices()
> >
> > Why isn't UEFI disabling the watchdog initialized by efibootguard when
> > ExitBootServices() is called?
> >
> > [1] UEFI Spec 2.6, EFI_BOOT_SERVICES.SetWatchdogTimer():
> >
>
> Actually, this limitation of the UEFI-specified watchdog is one of the
> reasons EFI Boot Guard exists. Here, we don't use the UEFI-provided
> watchdog but real ones (including those described via WDAT, but those
> are HW watchdogs as well). And those real watchdogs will not stop when
> the boot services are terminated. Rather, Linux will pick them up and
> continue to drive them.

Just for reference, here's EDK2's event-based watchdog implementation:
https://github.com/tianocore/edk2/blob/master/MdeModulePkg/Universal/WatchdogTimerDxe/WatchdogTimer.c#L208
This one supervises the EFI domain until the ExitBootServices() call ―
including a stalled EFI Boot Guard prior to having enabled a hardware
watchdog.

After EFI Boot Guard has enabled a hardware watchdog, this is
additionally running and not affected by ExitBootServices() as
UEFI doesn't care about it. With this, you bridge the gap between
ExitBootServices() and the Kernel driving the hardware watchdog
not being watchdog-supervised.

Technically, EFI Boot Guard's watchdog drivers could've also been
implemented as a set of UEFI drivers with the same effect (but a
harder deployment), then leaving only the switching logics to EFI
Boot Guard.


Kind regards,
Christian

--
Dr. Christian Storm
Siemens AG, Technology, T RDA IOT SES-DE
Otto-Hahn-Ring 6, 81739 München, Germany

[Jan Kiszka]

Honestly, I have no clue how UEFI implementations map the watchdog API
requests on real hardware. So far, we have not seen any conflicts in
practice, probably because that UEFI watchdog service is generally not
requested (definitely not by EFI Boot Guard).

Adding Francois for this topic. Maybe he can shed a light on the
interaction of SetWatchdogTimer() and hardware watchdogs.

[Christian Storm]

> >>> This project is what I have been looking for (secure boot + watchdog),
> >>> but I have a hard time grasping why it works.
> >>>
> >>> The UEFI spec states[1]:
> >>> "The watchdog timer is only used during boot services. On successful
> >>> completion of EFI_BOOT_SERVICES.ExitBootServices() the watchdog timer is
> >>> disabled."
> >>>
> >>> So the boot looke something like this (AFAIU):
> >>> 1. efibootguard starts
> >>> 2. efibootguard initializes the watchdog
> >>> 3. LoadImage()
> >>> 4. StartImage()
> >>> 5. Linux starts and calls ExitBootServices()
> >>>
> >>> Why isn't UEFI disabling the watchdog initialized by efibootguard when
> >>> ExitBootServices() is called?
> >>>
> >>> [1] UEFI Spec 2.6, EFI_BOOT_SERVICES.SetWatchdogTimer():
> >>>
> >>
> >> Actually, this limitation of the UEFI-specified watchdog is one of the
> >> reasons EFI Boot Guard exists. Here, we don't use the UEFI-provided
> >> watchdog but real ones (including those described via WDAT, but those
> >> are HW watchdogs as well). And those real watchdogs will not stop when
> >> the boot services are terminated. Rather, Linux will pick them up and
> >> continue to drive them.
> >
> > Thanks for the explanation, is the "UEFI-specified watchdog" not using
> > the hardware watchdog?

No, it's usually using an event-based mechanism, see, e.g. EDK2. That said,
there *could* be an EFI implementation using a hardware watchdog instead
of the event-based mechanism. Then, EFI Boot Guard would re-initialize
the watchdog. If this gets disabled on ExitBootServices(), then we have
a problem. However, I have not encountered this in the field.

> > or how is efibootguard preventing UEFI from
> > messing with the watchdog?

Usually, UEFI doesn't know or care about the hardware watchdog (see
above), so it's left alone and no special measures need to be taken.

> > According to the spec UEFI will disable the watchdog when
> > ExitBootServices() is called. I assume that is still happening with
> > efibootguard?

Yes, UEFI disables its own event-based watchdog ― and the timer mechanism
used for this is not available beyond boot services.

> Honestly, I have no clue how UEFI implementations map the watchdog API
> requests on real hardware. So far, we have not seen any conflicts in
> practice, probably because that UEFI watchdog service is generally not
> requested (definitely not by EFI Boot Guard).

The event-based mechanism watchdog is running unconditionally with
a 5 minute timeout per default. This is why some bootloaders reset
the value via BS->SetWatchdogTimer(5 * 60, WATCHDOGCODE, 0, NULL)
prior to starting the chain-callee so to give it the whole 5 minutes.

[François Ozog]

Hi Jan

This is indeed a problem as EFI spec is somewhat loose and also do not take into account hardware watchdogs. We have a bunch of boards for which implementation is tricky and have not found yet satisfactory solution. Ultimately we will define a behavior in Linaro Trusted Substrate , the reference implementation of SystemReady from Arm. Arm can’t go beyond UEFi spec but Linaro will make that extra step because that is needed for product makers.

Cordially 

FF

--

François-Frédéric Ozog | Director Business Development T: +33.67221.6485 franco...@linaro.org | Skype: ffozog