0

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?)

zee_ro
  • 3
  • 2
  • You need a copy of the actual UEFI specification. https://uefi.org/specifications – prl Nov 22 '22 at 09:19
  • I am agree with you that the original specification is the primary source. My aim is to get an insight and context towards my studies of the original specifications. – zee_ro Nov 23 '22 at 02:23

1 Answers1

1

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.

prl
  • 11,716
  • 2
  • 13
  • 31
  • Thank you. This is a good answer. I also have another question, which may deserve to be in a separate thread. What essential information does the UEFI firmware provide to the modules it is booting? I am referring to the kernel images mostly. – zee_ro Nov 23 '22 at 03:02
  • Concerning (2). Is there a way in general to restrict the UEFI RtS into a separate isolated compartment? I imagine, it could be a separate VM under a hypervisor. The [SetVirtualAddressMap()](https://edk2-docs.gitbook.io/edk-ii-uefi-driver-writer-s-guide/5_uefi_services/readme.3/5313_setvirtualaddressmap) should be the function to accomplish this. – zee_ro Nov 23 '22 at 03:05
  • The main pieces of essential information provided by UEFI are the memory map and the ACPI tables. Of course the ACPI tables contain a lot of stuff. – prl Nov 23 '22 at 05:07
  • Once the OS gets control of the platform, it can restrict anything it wants. Any OS should limit access to the runtime services to the kernel. I don't really see a reason that it would want to restrict it further. – prl Nov 23 '22 at 05:15
  • Thank you for sharing this. The access to ACPI tables is a familiar matter, and I don't think it requires any bootloader support. Considering memory maps, could you please suggest the part of specification that mentions these transactions? What I'm looking for is an exhaustive set of arguments that the firmware provides to an OS. Partially, this is motivated by the need to understand the role of OVMF in Xen (context: emulation of efi firmware config option), and what real alternatives I could have in that regard. – zee_ro Nov 23 '22 at 08:49
  • With a legacy BIOS, software is required to search for the ACPI tables in a defined set of areas of memory. With UEFI, such a search isn't guaranteed to work. Software is expected to use the ACPI table pointer passed by the firmware. – prl Nov 23 '22 at 18:43
  • Section 7.2 of the spec describes the GetMemoryMap function. – prl Nov 23 '22 at 18:47