That new versions of UEFI standards are prepared for us, part one, PI 1.4

After six months of development, the organization UEFI Forum has finally laid out in open access documentation on new standards Platform Initialization 1.4, Advanced Configuration and Power Interface 6.0 and Unified Extensible Firmware Interface 2.5, on the basis of which an absolute majority of PC and server firmware are being developed.
Usually between the release of new versions of standards and the first firmware on their base usually passes from 4 to 6 months, but now it is possible to predict with a high degree of probability which new features will appear in UEFI for platforms based on Intel Skylake and AMD Falcon Series processors.
I decided to divide the description of innovations into 3 parts, otherwise it risks being very long and no one will read it. If you are interested in the innovations described in the standard PI 1.4 and my comments to them - welcome under cat.

Very short introduction

If suddenly you are frightened by unfamiliar terminology, or you cannot understand what this is all about, read here this my article and come back.
Perhaps the average person will be of little interest in describing new PPIs and protocols, especially since they can be taken directly from the documentation, so I will try to dilute the boring enumeration of changes with comments about what the UEFI developer may need them and what their users are threatened with.

UEFI Forum tells and shows

Together in the documentation UEFI Forum published this press release , from which, after clearing the marketing bullshit, the following remains:
All standards

• NVM support: support for RAM that saves data when the machine is turned off, the so-called NVDIMM .

PI 1.4

• Graphics PPI: launching the graphics subsystem during the PEI phase.
• Multi-processor PPI: Initialize all available processors and cores during the PEI phase.
• Capsule PPI: detection of images with updates in the UEFI Capsule format, assembling them into a continuous memory area and transferring them to the DXE phase.
• No Execute Support: protects the firmware from a compromised hypervisor / OS.

ACPI 6.0 :

• CPU Topology Recognition: determine the topology of the CPU, allows you to more accurately manage the components of SoC and reduce their power consumption.
• Source Language Evolution: Improved syntax for the ASL language in which ACPI call handlers are written.

UEFI 2.5 :

• Boot From HTTP: A new way to boot over the network, replacing PXE.
• Platform Recovery: a new standard for ways to restore the integrity of the firmware when it is impossible to boot the system.
• Connectivity Support: Bluetooth and Wi-Fi / EAP2 support.
• High Assurance Enterprise Replacement: a new system for automatically deploying updates.

All this is wonderful, of course, but not very informative, and the list of changes is far from complete, so we will go the other way. Let it be that, using the Beyond Compare utility, compare 7 PDF files of the old standard with the corresponding files of the new one, find all significant changes and understand why they are needed and what they threaten. Let's get started

Changes in Platfrom Initialization

The standard for PI consists of 5 volumes describing the phases of PEI, DXE, SMM, common architectural elements of the firmware and equipment interaction protocols. Let's go through the changes in them in ascending order numbers.
')

Volume 1. Pre-EFI Initialization

ResetSystem2

A new function ResetSystem2 and its corresponding PPI have been added to EFI_PEI_SERVICES. The new function differs from the usual ResetSystem and its PPI by parameters and has the following signature:

VOID ResetSystem2 (IN EFI_RESET_TYPE ResetType, IN EFI_STATUS ResetStatus, IN UINTN DataSize, IN VOID *ResetData OPTIONAL); 

The type can be one of the following values: EfiResetCold, EfiResetWarm, EfiResetShutdown, EfiResetPlatformSpecific, where EfiResetCold is a “cold” reboot, i.e. reset and re-initialization of the processor, chipset and everything connected to them, EfiResetWarm is a “soft” reboot, i.e. resetting only the processor, EfiResetShutdown means shutting down the machine, and EfiResetPlatformSpecific — the reset type is determined by the GUID passed to ResetData.

A useful feature, especially pleased with the opportunity to perform a Shutdown directly from PEI (previously it was necessary to fence platform-dependent crutches) and transfer the reset status (ie, whether it is full-time or not, and if not, why it happened).

SEC Platform Information 2 PPI

New PPI for getting information not only about BSP , about other processors and cores. It will be needed for PPI below.

EFI MP Services PPI

PPI for early initialization of all processors and cores. Allow to initialize and use several cores in PEI.

PEI Recovery Block IO 2 PPI

New block device driver for PEI recovery mode. It can be used to implement the standard PEI Recovery mechanism, now each vendor comes up with something of their own, and almost always it works its own hands very badly. Let's see what the standard implementation is.

PEI Capsule PPI

PPI to build multiple updates in UEFI Capsule format into one contiguous memory area and transfer this area to the DXE driver, which will perform the update. Allows you to implement a firmware update in parts, while not communicating with Intel BiosGuard and similar vendor-specific solutions.

Volume 2. Driver Execution Environment Core Interface

New types of EfiGcdMemory

UEFI makes for itself and the OS a memory card, which is filled with the AddMemorySpace () function, which looks like this:

 EFI_STATUS AddMemorySpace(IN EFI_GCD_MEMORY_TYPE GcdMemoryType, IN EFI_PHYSICAL_ADDRESS BaseAddress, IN UINT64 Length, IN UINT64 Capabilities); 

The first parameter indicates the type of added memory area, which is selected from the following options:

 typedef enum { EfiGcdMemoryTypeNonExistent, EfiGcdMemoryTypeReserved, EfiGcdMemoryTypeSystemMemory, EfiGcdMemoryTypeMemoryMappedIo, EfiGcdMemoryTypePersistent, EfiGcdMemoryTypeMoreReliable, EfiGcdMemoryTypeMaximum } EFI_GCD_MEMORY_TYPE; 

The last two types, Persistent and MoreReliable, have been added in this update.
The Persistent type will be used for NVDIMM and other non-volatile storages mapped directly to the BSP address space, and the MoreReliable type will be used for “more reliable” memory, for example, for the local BSP memory that is part of the NUMA cluster.
Along with the addition of two new types of memory, the corresponding attributes EFI_RESOURCE appeared:

 EFI_RESOURCE_ATTRIBUTE_PERSISTENT EFI_RESOURCE_ATTRIBUTE_PERSISTABLE EFI_RESOURCE_ATTRIBUTE_MORE_RELIABLE EFI_RESOURCE_ATTRIBUTE_READ_ONLY_PROTECTED EFI_RESOURCE_ATTRIBUTE_READ_ONLY_PROTECTABLE 

I will not describe them, because the names speak for themselves.

In the remaining volumes, there are no important changes at all, only a couple of new GUIDs for new PPIs and fixes.

Conclusion

The changes, at first glance, are positive, but a bit frightening.

The fact is that writing PEI modules is a very nontrivial exercise due to specific requirements for them, and debugging such modules (especially those that are executed before initializing RAM) is even more trivial, and therefore I would like to have the minimum amount of code in PEI ( just the principle of less code - less bugs). I understand why PPI was added to the standard for graphics and multi-core, and they were added as optional, but I’ll have to reverse the buggy PEI module of the video card to understand what the hell it doesn’t work, but about the consequences of a sudden multithreading, where it was not and was not planned, I would prefer to remain silent. Let's hope that these optional PPIs are simply not implemented by anyone and they will remain on paper.

About innovations of the ACPI 6.0 standard - in the second part, about UEFI 2.5 - in the third.
Thank you for your attention and bugless firmware for you.

PS
The attentive reader has already noted that the support for NX , which is advertised in a press release, was never said, but this is because it is not part of the standard, but implemented separately through the work of Phoenix engineers . Implemented correctly, we hope for early implementation.