How Kernels Use UEFI Runtime Services for Wakeup Alarms

Modern operating system kernels interface directly with platform firmware through Unified Extensible Firmware Interface (UEFI) Runtime Services to control low-level hardware states that persist beyond the boot phase. When scheduling hardware-level wakeup alarms, kernels invoke standardized firmware interfaces, specifically the UEFI Time Services, bypassing the need for motherboard-specific register programming. This article explains the underlying mechanisms modern kernels use to map runtime firmware memory, invoke the SetWakeupTime() service, and program hardware real-time clocks (RTC) for system wakeups.

Preserving UEFI Services Post-Boot

During the boot sequence, the firmware provides two classes of services: Boot Services and Runtime Services. Once the kernel prepares its own memory management subsystems, it calls ExitBootServices(). This invalidates the Boot Services and reclaims their associated memory.

Runtime Services, however, remain resident in memory. The kernel inspects the UEFI memory map to identify regions flagged as EfiRuntimeServicesCode and EfiRuntimeServicesData. The kernel maps these physical memory ranges into its own virtual address space, traditionally using SetVirtualAddressMap() during initialization, or through dedicated isolated page tables in modern implementations to enhance security and isolation against buggy firmware implementations.

The SetWakeupTime() Runtime Service

UEFI standardizes access to the hardware Real-Time Clock through the EFI_RUNTIME_SERVICES table. To manage wakeup events, the specification defines two primary functions:

  • GetWakeupTime(BOOLEAN *Enable, BOOLEAN *Pending, EFI_TIME *Time)
  • SetWakeupTime(BOOLEAN Enable, EFI_TIME *Time)

When scheduling an alarm, the kernel prepares an EFI_TIME structure populated with the target year, month, day, hour, minute, second, and timezone data. The kernel calls SetWakeupTime(), passing TRUE to enable the alarm along with the pointer to the target EFI_TIME struct, or FALSE with a NULL pointer to clear an existing alarm.

Behind this abstraction, the platform-specific firmware handles the low-level communication with the hardware RTC or Power Management Integrated Circuit (PMIC), programming the appropriate alarm match registers and enabling the corresponding interrupt lines.

Kernel Implementation and Abstraction Layers

Operating system kernels abstract firmware calls behind standard user-space APIs so applications do not directly interact with UEFI interfaces.

Linux Implementation

In Linux, this functionality is primarily handled by the rtc-efi driver within the RTC subsystem:

  1. User Space Interface: Applications or utilities (such as rtcwake) write an epoch timestamp to /sys/class/rtc/rtcX/wakealarm.
  2. Subsystem Translation: The generic RTC framework verifies permissions, converts the target timestamp into standard date-time representations, and dispatches the request to the underlying driver via the set_alarm callback.
  3. Firmware Invocation: The rtc-efi driver converts the values into an EFI_TIME struct and invokes the function pointer located at efi.set_wakeup_time.
  4. Context Switching: Because UEFI runtime code is external to the kernel, Linux wraps the call in an execution context with interrupts disabled, a dedicated firmware stack, and specific page table mappings to safeguard the kernel space against memory corruptions.

Windows Implementation

In Windows, the Hardware Abstraction Layer (HAL) acts as the intermediary. When a program creates a timer using the CreateWaitableTimerEx() API with the CREATE_WAITABLE_TIMER_HIGH_RESOLUTION or resume flags, the Windows Power Manager processes the request. If the system is entering a Modern Standby or ACPI S3/S4 sleep state, the HAL invokes the UEFI Runtime Services table directly to ensure the platform hardware triggers the system resume.

Hardware Event Routing

Once SetWakeupTime() successfully executes:

  1. The firmware sets the RTC hardware alarm registers.
  2. The RTC alarm interrupt line is routed to the platform's Advanced Configuration and Power Interface (ACPI) hardware logic or the primary interrupt controller.
  3. When the RTC counter matches the programmed alarm value, the RTC asserts an interrupt (such as an ACPI System Control Interrupt, or SCI).
  4. The platform power-management hardware detects the assertion, transitions the power delivery states back to full operation, and hands execution back to the kernel's resume vector.