UEFI Forum Releases the UEFI 2.11 and the PI 1.9 Specifications

[Nomad76]

The UEFI Forum today announced the release of the Unified Extensible Firmware Interface (UEFI) 2.11 specification and the Platform Initialization (PI) 1.9 specification. The goal of these specification updates is to streamline user implementation by providing increased compatibility across hardware architectures, including security updates, algorithm support and improving alignment implementation guidance.

"We have created a vibrant firmware community, and these specification updates provide maintenance and enhancement of fundamental capabilities in order to help increase the momentum of the UEFI specifications and add value to the ecosystem," said Mark Doran, UEFI Forum President. "The latest specifications continue the UEFI Forum's commitment to developing standards for all significant CPU architectures as underscored by additions such as the new LoongArch support in the PI 1.9 specification."



Key UEFI 2.11 Capabilities:

• Updates to memory management and allocation, such as the new memory attribute for hit plug and Arm memory allocation mandates
• Enhancements to protocols, algorithms and boot management
• Corrections to EFI_KMS_PROTOCOL, new crypto algorithms and support for Proxy Host URI in HTTP Boot
• Improvements to error handling and documentation updates, including Common Platform Error Record (CPER) definitions and Arm processor error information

Key PI 1.9 Capabilities:

• Expands algorithm options by providing enhanced security with additional cryptographic algorithms for signed Firmware Volume (FV) and signed sections extending beyond the previous RSA2048_SHA256
• Adds Random Number Generator (RNG) PEIM-to-PEIM Interface (PPI) to serve as an entropy source for seeding other cryptographic services, allowing platforms to provide RNG services in PEI across binary boundaries effectively
• Includes new protocol for Multiple SPI Regions with varying block erase sizes, enhancing flexibility and functionality
• Adds support for LoongArch architecture, broadening the range of supported systems

To learn more, view the UEFI 2.11 specification and PI 1.9 specification on the UEFI Forum Specification webpage.

View at TechPowerUp Main Site | Source

 

[lexluthermiester]

So in simpler terms, a number of glaring problems have now been resolved.

 

[trsttte]

When will ARM platforms adopt this? It would make support much easier

 

[igormp]

When will ARM platforms adopt this? It would make support much easier

Server ARM platforms do support UEFI by default (such as Ampere's products).
For SBCs, since they have their own custom firmware, you usually need to build your own bootloader and then you're free to boot something like edk2 on top of it for UEFI support.

 

[Vincero]

So in simpler terms, an number of glaring problems have now been resolved.

A shame they don't improve multi-boot OS scenarios and bootloaders nuking each other. Whilst for sure, there is a large responsibility for OS installers to get it right, UEFI implementations with inconsistent approaches to how they list boot entries is still (for many motherboards and OEM system makers) a bit of a joke.

 

[lexluthermiester]

A shame they don't improve multi-boot OS scenarios and bootloaders nuking each other.

Agreed. That is a problem that needs to be resolved.

 

[:D:D]

A shame they don't improve multi-boot OS scenarios and bootloaders nuking each other.

Not aware of this, would you mind expanding, thanks. FWIW I've only seen "Windows attempting repairs" do something like this, destroying other systems on the UEFI system drive and then saying it wasn't able to fix it, FUBAR. Not always like that but always scares me when Windows gives that message! Now Windows has it's own system drive, not shared.

 

[Vincero]

Not aware of this, would you mind expanding, thanks. FWIW I've only seen "Windows attempting repairs" do something like this, destroying other systems on the UEFI system drive and then saying it wasn't able to fix it, FUBAR. Not always like that but always scares me when Windows gives that message! Now Windows has it's own system drive, not shared.

Yeah, to be fair the problem isn't Windows as an OS, but the decisions made for that repair process - it basically assumes a) the user isn't aware of other OS on the system, and b) any EFI components not meant to be there are, well, just not meant to be there. It's a bad/obnoxious way to operate, but I guess for 99% of the user scenarios out there its the right one, and that other 1%.... well I guess MS knows we love them like that weird uncle who's now in prison that was always a bit too handsy when we were growing up.

To be fair, the GRUB and Windows Boot Manager installation routines do try to co-exist with other OS on the same drive - you can have Windows correctly identify and list a non-MS OS in it's boot screen and the same with GRUB listing Windows. It's just a shame that with Windows EFI, the boot options are only shown once Windows has part loaded most of the OS to show the boot options - picking another OS basically restarts the system and loads that one.
GRUB is more like the older NT4/2K/XP boot manager methodology where it will display the OS options as soon as the boot loader runs, and picking an OS then just starts that OS.

My bigger issue is how the BIOS will hande the EFI options. The BIOS will scan the EFI partition and boot whatever it finds, but the implementation and management of this on various BIOS UEFI implementations is literally all over the place. I've seen some hard-coded to only accept 'Windows Boot Manager' (admittedly old systems), some which will list out multiple EFI options but list them all as 'Windows Boot Manager' or some such even though one may be windows and another may be Linux (e.g. Ubuntu will normally appear as 'ubuntu' on an EFI list when done properly).
Worse still, on some BIOS UEFI implementations, if you wipe the system drive and install a new OS, the existing EFI boot options are still in the list (admittedly, now lower in order) so you just have duplicate entries that are pointless.

But due to that behaviour of newer EFI Windows OS and multiboot - where you need to wait for Windows to part boot before being able to choose the OS you want and it then restarts to finally load that other OS - not one system / motherboard vendor that I'm aware of (out of the big mainstream vendors) seems to have added an option to display an EFI boot loader choice at boot-up, with it fail-over to the last choice used if no input within xx seconds (which would make sense if doing updates on a remote/headless box).
People shouldn't need to look at using and manually tinkering with something like Clover, GRUB or other options to achieve this. If BIOS vendors have enough ROM space for LED light control, fan profiles, and storing multiple OC/fan and BIOS settings in different profiles, I think they can crack this problem.

And don't get me started on TPM and the alien concept of having more than one OS on the same system...

 

[igormp]

I've seen some hard-coded to only accept 'Windows Boot Manager' (admittedly old systems), some which will list out multiple EFI options but list them all as 'Windows Boot Manager' or some such even though one may be windows and another may be Linux (e.g. Ubuntu will normally appear as 'ubuntu' on an EFI list when done properly).

I faced that once, had a B550 motherboard (don't remember if it was an Asrock or MSI one) that only wanted to boot the Windows' bootloader EFI file it if was present by any reason.
I had a leftover windows .efi from years ago in a disk that didn't even had windows, and found it weird why I wasn't able to boot by any means, until I noticed the firmware was straight away ignoring the options I had set for boot order and whatnot. Removing the windows .efi did the trick, but also if I just renamed my systemd .efi to match the windows one (EFI/Microsoft/Boot/bootmgr.efi) it would always force boot it no matter what.

Worse still, on some BIOS UEFI implementations, if you wipe the system drive and install a new OS, the existing EFI boot options are still in the list (admittedly, now lower in order) so you just have duplicate entries that are pointless.

Yeah, that's likely bad handling of the nvram, could be either the firmware itself or the software installing stuff.

not one system / motherboard vendor that I'm aware of (out of the big mainstream vendors) seems to have added an option to display an EFI boot loader choice at boot-up

Usually you can select the boot order in your UEFI settings, and those are often the different .efi files found across your FAT32 partitions across your disks, but yeah, no such thing at boot-up unless you go directly into the efi shell