UEFI Runtime Service Near OS

Question

I had the idea of ​​starting a small service next to the OS, but I'm not sure if this is possible. I tried to understand this by reading some documents, but did not go far, so here my question arises.

I read about UEFI time services.
Will it be possible to have a small module in the firmware that works next to the operating system you are using and sends information about the location of the device to an address on the Internet?

As far as I know, I would say that it should not run something in the background as soon as UEFI transferred control to the kernel of the OS.

To clarify my intentions, I would like to have something similar on my laptop. There is a Prey project, but it is installed inside the OS. I am using a Linux distribution without an autologue. If someone steals it, they will probably just install Windows.

Answer 1

What you want to do is prohibited, as it will be a gateway to viruses, registrars and other malwares.

However, if you want some code to work away from the OS, you should look at the system management mode (SMM).

SMM is the execution mode of x86 processors orthogonal to standard secure modes. SMM allows the BIOS to completely suspend the OS on all CPUs at the same time and enter SMM mode to perform some BIOS services. Switching to SMM mode is happening right now on your x86 machine when you read this Stackoverflow answer. It starts either:

• hardware : a dedicated system control interrupt line (SMI #), very similar to IRQ,
• : through I / O access to the location-specific logic of the motherboard (port 0xb2 is shared).

SMM services are called SMM handlers, and, for example, sensor values ​​are very often retrieved using an SMM call to the SMM handler.

SMM handlers are configured during the DXE phase of initializing the UEFI firmware in SMRAM, an area reserved for SMM handlers. See the following diagram:

SMM drivers are sent by the SMM core during the DXE phase. So additional SMI handlers can be registered in the DXE phase. At the end of the DXE phase, when you no longer need to send SMM drivers, SMRAM will be blocked (as recommended). When the SMRAM is locked, no additional SMM drivers can be sent, so additional SMI handlers can be registered. For example, the SMM driver that registers the SMI handler cannot be loaded from the EFI shell or added as DriverOption in the UEFI boot manager.

source: tianocore

This means that the code of your SMM handler must be present in the BIOS image, which means rebuilding the BIOS with the addition of a handler. This is complicated, but there are tools that provide both a DXE environment and embedded SMM handler code in a PE executable, as well as other tools for adding a DXE driver to an existing BIOS sample. However, not all BIOS manufacturers are supported. This is risky if your flash chip is not in the socket and you can reprogram it from the outside.

But first you need to check if SMRAM is blocked on your system. If you're lucky, you can add your own SMM handler directly to SMRAM. It is not easy, but doable.

Note The SMM processors inside the BIOS are OS independent, so it starts even if the burglar installs a new operating system, which is what you need. However, being outside the OS has huge drawbacks: you need to implement a driver for the network interface in your SMM processor (only for polling, without interruption!) And wlan 802.11, DHCP and IP support for connecting to Wi-Fi, and your data will be redirected to an external host on the Internet. How do you determine your Wi-Fi SSID and password? Well, you can wait for the OS to initialize the network adapter for you, but you will need to save / restore the full state of the network host controller between calls. Not a small or simple project.

Answer 2

As far as I know, I would say that it should not run something in the background as soon as UEFI transferred control to the kernel of the OS.

I agree. Of course, the boot environment (before ExitBootServices() uses only one threading model.

There is no concept of threads in the UEFI specification, as far as I can tell. In addition, each run-time service is what the OS intentionally calls, just as the OS provides system calls for applications. After entering the runtime system function, note the following limitation from 7.1:

Subscribers are prohibited from using some other services with another processor or on the same processor after interruption, as indicated in table 30.

Depending on which parts of the UEFI firmware you need access to the runtime service, it depends on which features of the firmware will not be reentrant while your call has been busy.

In other words, even if you were willing to sacrifice a thread to sit forever inside the EFI time service, you could block the rest of the kernel from using other runtime services.

I don’t think it will be possible, unfortunately, but an interesting question anyway!