Search code examples
bootloaderbootuefixenacpi

UEFI Runtime Services: Role and Function Within an OS

I would like to understand how the UEFI Runtime Services function within the OS. I would also like to understand, how essential are those service for the proper functioning of an OS.

I am aware that the UEFI Runtime Services are invoked in the DXE phase of boot on an UEFI system. Please correct me if I am wrong, I understand that those services are run in a more privileged ring of the CPU than the OS (which is at ring 0). I also have read that the Runtime Services could continue execution after the bootloader launches an OS kernel. Could you please clarify the following issues:

  1. In what memory space do the Runtime Services run? Is it standardized? Is that memory space a region within main memory (e.g. the DDR RAM)? [1]
  2. How are Runtime Services scheduled on the CPU? How is control transferred to them? Should they necessarily run in parallel?
  3. I recall issues with System Manager Mode on PC hardware that were being coded around in Linux kernel. Specifically, the SMM had been causing unpredictable delays due to unpredictable control flow transitions. Is the situation similar with the Runtime Services?

I am aware that the ACPI has been a source of most system-specific information for OS, especially concerning a set of essential memory regions. Please correct me if I am wrong, I understand that it was possible to load an OS from BIOS without any additional information passed to the OS, and with OS only getting the system-specific information through the ACPI. As I understand it, certain basic functionalities, like power-on and power-off, as well as sleep had been implemented through ACPI in Linux and BSD system running on PC hardware. Since the ACPI specifications are a part of UEFI specifications, I see no reason why the OS could not get all the system-specific information it needs to run, and why it would not be able to invoke the ACPI functions. Could you please clarify the following issues:

  1. Are the UEFI Runtime Services essential for the operations of an OS like Linux or *BSD?
  2. Could this essential functionality be replaced by the ACPI? What additional functionality do the Runtime Services provide?

Finally, it has been suggested that the ability to use UEFI Runtime Services may depend on the bootloader support. Could you please help me to clarify:

  1. Does the availability of UEFI Runtime Services depend on the support of the bootloader?
  2. (If yes to (7), then...) Why would the absence of bootloader support affect the ability to use UEFI Runtime Services? Let's disregard the difficulties with acquiring a pointer to the memory location with the relevant function pointers. Would the services be still running in the background, if the relevant bootloader support is absent?

I've consulted the following sources:

  1. https://wiki.osdev.org/UEFI
  2. https://wiki.osdev.org/Using_UEFI_Runtime_Services_in_your_Kernel
  3. https://wiki.xenproject.org/wiki/Xen_EFI

Footnotes

[1] There's a partial answer to this question provided here. It is still unclear whether the memory space in question is in main memory, and whether in general an OS or a hypervisor could have access to it. (That, is it actually a standardized codified semantics?)

Solution

  • 1. All code and data are in main memory. There are not standardized locations. There are no standardized data structures other than the runtime services table, which provides pointers to the runtime services functions. The BIOS allocates pages of main memory for its own operation and marks them as "Reserved" in the memory map that is passed to the OS, so the OS knows that it cannot use those pages. They are not protected from the OS, though.

    2. Runtime services only get control when they are explicitly called by the OS. They run with the same privilege they are called from, not a higher privilege. There is no scheduling. There are restrictions on which runtime services can be called simultaneously, documented in section 8.1 of the UEFI spec.

    3. SMM can be invoked asynchronously to the OS software flow and in many situations it requires all hardware threads to enter SMM before the event can be handled. This causes a significant hiccup in OS operation. Since UEFI runtime services only gain control when explicitly called by the OS, this problem does not occur.

    4. No UEFI runtime services are essential.

    5. The categories of UEFI runtime services are Variable Services, Time Services, Virtual Memory Services, and Miscellaneous. See chapter 8 of the UEFI spec for details. Other than Reset System, I don't think there is any overlap with ACPI services.

    7. The only requirement of the boot loader is that it pass the pointer to the runtime services table to the OS.

    8. UEFI runtime services don't run in the background.