Skip navigation
ElectronicsGLOBAL_889231252.jpg

What’s the Difference Between UEFI 2.8 and Previous Specifications?

As new capabilities are established in hardware, new capabilities running on silicon must be supported in the software running on top of it. The UEFI Specification, which was recently updated to Version 2.8, is up to the task.

People don’t often think about their platform firmware, but it’s an integral part of every computer and many other electronic devices. Firmware is simply any computer program that’s tightly linked to hardware, such as processor machine instructions for bootstrap loaders or the control systems for electronic devices. The Unified Extensible Firmware Interface (UEFI) Forum developed the UEFI Specification for firmware technology. It benefits both users and developers by supporting a more secure system, faster boot times, and speed of platform innovation.

Challenges with platform firmware derive directly from the hardware a system is running—it’s a ripple effect. As time moves forward, platform capabilities evolve as does the underlying firmware necessary to initialize and use them.

For instance, there was a time when hard drives larger than two terabytes didn’t exist. And, not surprisingly, when those hardware capabilities broke the two-terabyte barrier, the firmware interfaces had to change with the hardware. In addition, the UEFI Forum had to come up with a whole new partitioning scheme that had none of the inherent limitations of the previous standard partitioning scheme, while maintaining a level of backward compatibility.

We’ve seen such evolutions in capabilities and interfaces over and over again. As the old saying goes, “After all, nobody ever needed more than 640K of memory, right?”

Another example was the introduction of USB 2.0. To allow users to take advantage of the higher speeds, the UEFI Forum added support for those hardware advances in the then-newest specification. The specification needed to change because USB 2.0 required firmware APIs to use the faster interface. If current hardware couldn’t support certain security capabilities, for example, then augmentations needed be made so that developers could take advantage of new security capabilities, incorporate them, and make forward progress. The UEFI Forum’s Specification ensures the standardization of firmware interfaces to support this type of evolution.

What is the UEFI Specification?

The UEFI Specification defines a model for the interface between personal-computer operating systems and platform firmware. The interface consists of data tables that contain platform-related information, plus boot and runtime service calls that are available to the operating system and its loader. Together, these provide a standard environment for booting an operating system and running pre-boot applications.

As technology evolves, and new capabilities are brought about in hardware, we need to know that new capabilities running on silicon are supported in some fashion in the software that runs on top of it. This can be managed by firmware built according to the UEFI Specification. Many layers of software run on the bare-metal system. UEFI platform firmware manages system initialization and launching the OS, helping both hardware and software support new platform capabilities. Since 2006, the UEFI Forum has been updating UEFI Specifications. The specification was recently updated: Version 2.8 was released in March 2019. 

What’s New in UEFI Specification Version 2.8?

Representational State Transfer (REST), the software architecture that defines web-based services, provides interoperability between computer systems on the internet. The newest version of the UEFI Specification, Version 2.8, adds support for REST. By supporting REST, the updated version of the specification deals with all aspects of enabling firmware at the platform level, lending support for all parts of the operating system. 

Another new feature in the revised UEFI Specification is support for the Redfish manageability standard produced by the Distributed Management Task Force (DMTF). DMTF creates open manageability standards spanning diverse emerging and traditional IT infrastructures including cloud, virtualization, network, servers, and storage. Redfish is an API designed to deliver simple and secure management for converged and hybrid IT. It’s focused on platform firmware and provides a base platform for bare-metal systems. The added support for Redfish in the updated UEFI Specification extends to how the firmware helps manage a system, even when it’s managing or configuring remotely.

Additional Support for Memory Cryptography

When it comes to new technologies, two important considerations arise: how to set up RAM and how to support and initialize non-volatile dual inline memory modules (NVDIMMs). The updated version of the UEFI Specification contains expanded support for memory cryptography. It deals with memory-related issues by exposing and mapping memory ranges that can be protected using CPU memory cryptographic capabilities like encryption and creating memory maps.

Systems coming out now and in the future will have a mix of DRAM and NVDIMMs. Traditionally, memory was only DRAM, which meant that if the plug was pulled, all work would be lost. All formerly open programs couldn’t be saved. With NVDIMMs, the open programs can remain available if power is lost.

The UEFI Specification differentiates intuitively between a DRAM topography versus one that has both DRAM and NVDIMMs. Before Version 2.8, there was nothing in the specification that dealt with non-volatile memory. Within the memory map, it’s now possible to delineate regions that are specific to NVDIMMs. This is a huge and meaningful change because it enables the hardware capabilities that have been in development for the last couple of years but are only starting to be deployed today.

Conclusion

The updated UEFI Specification offers a way for all developers involved in a building process to speak the same language. This translates to the big advantage of a faster time-to-market. By defining and enabling capabilities without interfering with OEM value-add, the process is easier and faster for both OEMs and IHVs.

For the OEM, it’s much easier to point to the industry-standard specification and its features and say, “This is what I need.” For the IHV, it’s easier now to bid for a project and then reuse code for easy prototyping during the building process. The IHV will then be able to use the specification to avoid recreating the wheel for every development and can recoup some of the cost of innovation since other OEMs will be asking them for similarly designed hardware.

Silicon is always evolving, and while it does, there’s a great deal of work that needs to be done before a silicon feature can be employed in any sensible fashion. If a new silicon feature is deemed useful, the firmware initializing that platform will likely need to support it. Enabling these new features in the firmware causes a ripple effect in the industry, from bare-metal platforms, to IHVs, and all the way to operating systems.

The threads that run through this entire process and tie it all together are standards like the UEFI Specification. Just as you can’t raise the speed limit on the road unless you design the road without safe curves and a good plan for traffic flow, you can’t deploy something industry-wide without properly designed, and standardized, platform firmware.

To learn more about the UEFI Forum community, visit www.uefi.org. For more information on joining, check out www.uefi.org/membership.

Mark Doran is President of the UEFI Forum.

SourceESB banner with caps

Hide comments

Comments

  • Allowed HTML tags: <em> <strong> <blockquote> <br> <p>

Plain text

  • No HTML tags allowed.
  • Web page addresses and e-mail addresses turn into links automatically.
  • Lines and paragraphs break automatically.
Publish