That new versions of UEFI standards are being prepared for us, part three, UEFI 2.5

In the last part of the cycle, I will try to talk about the innovations of the UEFI 2.5 standard, the first implementation of which should appear in about six months on new motherboards with Intel Skylake and AMD R-Series processors. The first and second parts dealt with lower-level (and therefore less interesting to non-specialists) standards PI 1.4 and ACPI 6.0, here we will also talk about changes that directly affect the operation of the OS and the ability to boot via the network. If you want to know what's new in UEFI 2.5, why PXE is a thing of the past and why UEFI supports WiFi and Bluetooth - I sincerely ask for cat.

Unlike its low-level counterparts, the UEFI standard has been developing at a very high pace, and since the release of the previous version 2.4 of the Errata C, it has not been even half a year to go. There are a lot of changes, so I will try to filter out small and not very important ones, like corrections of typos and corrections of some parts of the text that allowed for a double interpretation. If this does not suit you and you need all changes to the last comma - the original document is at your service.

As in the previous part, I divided the changes into groups in order not to describe each new protocol several times. Go!

ESRT and new firmware upgrade method

UEFI 2.5 introduces a new optional ESRT table, with which UEFI can inform the operating system of the types and versions of existing firmware components, as well as the status of their last update.
Using this table, the OS can initiate an update not only of the entire firmware (as it was on almost all manufactured motherboards with UEFI), but also of specific independent components, such as VBIOS / GOP driver, Raid driver, UNDI - driver, etc. To initiate the update, the standard mechanism of UEFI Capsule Update will be used, and the update itself will be performed at the next boot. Component update files are protected from modification of RSA2048 / SHA256-based EDS and can be released only by the owners of the private key, so flashing the modified images (and it does not matter whether the modification was performed by a malicious virus or an experienced user) using Capsule Update will not exit, so the programmer still our everything.
ESRT will also be used to deliver updates through the OS components update subsystem (i.e. Windows Update for Win10 and fwupd for Linux).
')

SysPrep, OS Recovery and Platform Recovery

Initially, in the BDS phase, only one type of EFI application could be launched - the bootloader, which is also the EFI bootloader. The boot order is set in the BootOrder variable, and the path and parameters of the bootloader are stored in the variables Boot ####, starting with Boot0000 and ending with BootFFFF. Another type was added to UEFI 2.3 - the DXE driver, which will be started by the BDS dispatcher before running any bootloaders from Boot ####, and the corresponding DriverOrder and Driver #### variables are added along with the type. In version 2.4, added the ability to bind to the EFI-bootloader from Boot #### hotkey, which is stored in the variable Key ####. In the current version, and this was not enough, and 3 new types of applications were added at once: SysPrep , OsRecovery and PlatformRecovery .

Sysprep

Sometimes it turned out that it is too early to run any code from Driver #### (for example, you need a console or fully initialized hardware), and from Boot #### it is too late ( BS- variables are no longer available, you have to shamanize with BootOrder “ohm, to be guaranteed to run first, and there is a risk to break the download at all). To solve this problem, a third type of application is proposed - the System Preparation Application. Such applications run after the drivers, but before the bootloaders, and have access to the console and graphics mode. Applications of this type may include disk encryption, IPMI emulators, systems adapted UI for people with disabilities, etc. SysPrep applications are subject to the same restrictions as bootloaders, i.e. To use them with SecureBoot, they must be signed with a suitable EDS.
Perhaps it looks very useful, it remains to wait for the implementation and try to work.

OS Recovery

If none of the boot loaders could start the OS, then the OS can initiate boot repair, for which the variables OsRecoveryOrder and OsRecovery #### are used. This feature is only available to systems that support SecureBoot and for its use SecureBoot must be activated. When using it, applications from SysPrep and PlatfromRecovery will not load.

Platform Recovery

If none of the boot loaders could start the OS, then UEFI can also initiate boot loader recovery using data from PlatfromRecoveryOrder and PlatfromRecovery ####. Both of these variables are not available for modification from the OS, and will be used only when OS Recovery is not available. One of the PlatfromRecovery #### variables can be flagged with the Default Boot Behavior flag, i.e. the application specified in it will be launched in case nothing else could be started.
If both manufacturers of the above mentioned features are implemented correctly, then problems like this one can finally be forgotten.

Security

The new standard has several new protocols that are proposed to be used to control the integrity of the firmware and encryption components. The EFI_PKCS7_VERIFY_PROTOCOL protocol with two VerufySignature and VerifyBuffer functions allows you to check the integrity of both the digital signature (in the PKCS7 binary DER format), as well as the data signed by it. The EFI_HASH2_PROTOCOL protocol adds to the existing ability to calculate the hash sum from a continuous buffer of a predetermined size by a triple of HashInit, HashUpdate and HashFinal functions that allow you to calculate a hash from a data stream or several buffers at different ends of available memory. The EFI_BLOCK_IO_CRYPTO_PROTOCOL protocol adds the ability to read / write data with on-the-fly encryption
The standard also adds support for using NX-bits to protect buffers and data areas from execution.

NVM

As in the lower level standards, support for NVDIMM and other types of Persistent Memory has been added to UEFI 2.5. Basically, these are different definitions in the header files, but there was also a place for the new protocol - EFI_NVM_EXPRESS_PASS_THRU_PROTOCOL, which can be used to communicate with NVMe devices directly, transferring raw commands to detected NVMe devices and processing responses from them.

Network stack and network boot

HTTP download

The main innovation of the UEFI 2.5 standard is the addition of HTTP download as an alternative to the already existing implementation of UEFI PXE using the TFTP protocol. This required adding support for DNSv4, DNSv6 and HTTP itself, support for IPv6 with the UNDI driver, suggested changes for corporate DHCP servers and some other improvements. The final HTTP download scheme for the standard looks like this:

The loader is a standard UEFI application (to distinguish remote loaders from local loaders, they were called NBP in the standard), which, in order to be used with SecureBoot, must be signed with a suitable digital signature. NBP can use the network stack to load the following stages, so writing multi-stage loaders is now a small problem, unlike PXE.

WiFi and Bluetooth support

Also in the new standard appeared support for VLAN, WIFI and Bluetooth as components of the network stack. Along with it, a whole heap of new protocols appeared, such as EFI_WIRELESS_MAC_CONNECTION_PROTOCOL or EFI_BLUETOOTH_HC_PROTOCOL, which, if there is a driver for the hardware, will allow access to wireless networks from UEFI drivers and applications.
As a result, with UEFI 2.5 based firmware, you can boot the laptop's OS over WiFi from a remote HTTP (S) server without a very strong witch. I can’t say that I really need it or it makes me very happy, my inner paranoid grumbles a little, but if the network infrastructure is not needed, you can turn it off (and check that it is really disabled) or cut it out completely, this is also not very difficult.

Rest

There are still a lot of minor changes, about which there is almost nothing to tell: support for smart card readers, which can be used as data sources for various types of cryptography, new EFI_USBFN_IO_PROTOCOL protocol for low-level communication with USB devices, new EFI_REGULAR_EXPRESSION_PROTOCOL protocol and HII opcode EFI_IFR_MATCH2, which is the most RegExp protocol will use, several new types of DevicePath nodes - BMC , SD card, RAM disk, and so on, do not list everything.

Conclusion

My overall impression of the new versions of UEFI standards is rather positive. I can not say that all changes are expected or very necessary for a simple user, some will be able to “shoot” only with the competent implementation of the standard by the developers of UEFI platforms (ie, AMI, Insyde, Phoenix, etc.), and some are very developers will like it (ASL 2.0 FTW!), but ultimately my verdict will go. Let's see, of course, whether it will be possible to implement everything that looks smooth on paper, but I hope that in six months I will not have to write an article like “why the UEFI HTTP Boot does not work and how to deal with it”.
Thanks to the reader for your time, and successful firmware.