Now they are doing it again with the PI 1.2.1 specification. Let's dig in and take a look at what really changed:
- The Security Architecture Protocol was cleaned up. The SAP is used by the DXE Core to authenticate an image before allowing it to be loaded. More recently, it is being used to handle pieces of the UEFI 2.3.1 Secure Boot infrastructure and TCG measurement. The problem with SAP (which was addressed in SAP2) is that it didn't actually pass in a pointer to the image buffer, which forced SAP implementations to effectively reload the image from the storage device in order to get a good look at it. SAP2 addressed that, and with clarifications, proves faster for faster book.
- The SetMemorySpaceCapabilities function was added to GCD. Previously, the memory attributes (such as X and Y) were settable through SetMemorySpaceAttributes, but the capabilities were not changeable.
- A new event, End-of-DXE was added. Previously, there was no clear way to define the end of DXE and the beginning of the Boot Manager portion of the BDS phase. As a result, drivers were attempting to latch onto all sorts of implementation-specific behavior to make sure they were executed before BDS started. The new UEFI event, End-of-DXE, is guaranteed to be invoked before any UEFI drivers or applications are launched and before the console devices are connected.
- There is now a detailed Super I/O PEI and UEFI driver-model architecture to further standardize the process of adding super I/O device in a compatible way.
- New signed Firmware File System sections were added, using a header similar to the UEFI certificates to sign the file section contents.
- The new PCD Get Info Protocol and PPI add functions which return information about an individual PCD item.
- Added methods for reserving interrupt and exception vectors.
- Added support for weakly aligned Firmware Volumes. Previously a Firmware Volume's alignment was required and controlled the alignment of individual Firmware Files in the Firmware Volume. That is, if a Firmware Volume was aligned on an 8 byte boundary, it was impossible to include a Firmware File that required 64KB alignment. But this wasn't always useful or desirable, because Firmware Volumes were sometimes just used as containers of arbitrary files.