Channels ▼


The Evolution of the Unified Extensible Firmware Interface


The Platform Initialization Working Group (PIWG) is the portion of the UEFI forum that defines the various specifications in the PI corpus. The UEFI Specification Working Group (USWG) is the group that evolves the main UEFI specification. Figure 5 illustrates the layers of the platform and what the scope that the USWG and PIWG cover.

[Click image to view at full size]
Figure 5: PI/UEFI layering.

Over time, these specifications have evolved. Below we enumerate the recent history of specifications and the work associated with each:

  • UEFI 2.1
    • Roughly one year of Specification work
      • Builds on UEFI 2.0
    • New content area highlights:
      • Human Interface Infrastructure
      • Hardware Error Record Support
      • Authenticated Variable Support
      • Simple Text Input Extensions
      • Absolute Pointer Support
  • UEFI 2.2
    • Follow-on material from existing 2.1 content
      • Backlog that needed more gestation time
    • Security/Integrity related enhancements
      • Provide service interfaces for UEFI drivers that want to operate with high integrity implementations of UEFI
    • Human Interface Infrastructure enhancements
      • Further enhancements pending to help interaction/configuration of platforms with standards-based methodologies.
      • Networking
        • IPv6, PXE+, IPsec
      • Various other subject areas possible
        • More boot devices, more authentication support, more networking updates, etc.
  • UEFI2.3
    • ARM binding
    • Firmware management protocol

To complement the layering picture in Figure 5, Figure 6 shows how the PI elements evolve into the UEFI. The left half of the diagram with SEC, PEI, and DXE are described by the PI specifications. BDS, UEFI+OS Loader handshake, and RT are the province of the UEFI specification.

[Click image to view at full size]
Figure 6: Where PI and Framework Fit into the Platform Boot Flow.

In addition, as time has elapsed, the specifications have evolved. Figure 7 is a timeline for the specifications and the implementations associated with them.

[Click image to view at full size]
Figure 7: Specification and Codebase Timeline.

Platform Trust/Security

Recall that PI allowed for business-to-business engagements between component providers and system builders. UEFI, on the other hand, has a broader set of participants. These include the operating system vendors that built the OS installers and UEFI-based runtimes; BIOS vendors who provide UEFI implementations; platform manufacturers, such as multi-national corporations who ship UEFI-compliant boards; independent software vendors who create UEFI applications and diagnostics; independent hardware vendors who create drivers for their adapter cards; and platform owners, whether a home PC user or corporate IT, who must administer the UEFI-based system.

PI differs from UEFI in the sense that the PI components are delivered under the authority of the platform manufacturer and are not typically extensible by third parties. UEFI, on the other hand, has a mutable file system partition, boot variables, a driver load list, support of discoverable option ROMs in host-bus adapters (HBAs), and so on. As such, PI and UEFI offer different issues with respect to security. In general, the security dimension of the respective domains include the following: PI must ensure that the PI elements are only updateable by the platform manufacturer, recovery, and PI is a secure implementation of UEFI features, including security; UEFI provides infrastructure to authenticate the user, validate the source and integrity of UEFI executables, network authentication and transport security, audit (including hardware-based measured boot), and administrative controls across UEFI policy objects, including write-protected UEFI variables.

A fusion of these security elements in a PI implementation is shown in Figure 8.

[Click image to view at full size]
Figure 8: Trusted UEFI/PI stack.

Related Reading

More Insights

Currently we allow the following HTML tags in comments:

Single tags

These tags can be used alone and don't need an ending tag.

<br> Defines a single line break

<hr> Defines a horizontal line

Matching tags

These require an ending tag - e.g. <i>italic text</i>

<a> Defines an anchor

<b> Defines bold text

<big> Defines big text

<blockquote> Defines a long quotation

<caption> Defines a table caption

<cite> Defines a citation

<code> Defines computer code text

<em> Defines emphasized text

<fieldset> Defines a border around elements in a form

<h1> This is heading 1

<h2> This is heading 2

<h3> This is heading 3

<h4> This is heading 4

<h5> This is heading 5

<h6> This is heading 6

<i> Defines italic text

<p> Defines a paragraph

<pre> Defines preformatted text

<q> Defines a short quotation

<samp> Defines sample computer code text

<small> Defines small text

<span> Defines a section in a document

<s> Defines strikethrough text

<strike> Defines strikethrough text

<strong> Defines strong text

<sub> Defines subscripted text

<sup> Defines superscripted text

<u> Defines underlined text

Dr. Dobb's encourages readers to engage in spirited, healthy debate, including taking us to task. However, Dr. Dobb's moderates all comments posted to our site, and reserves the right to modify or remove any content that it determines to be derogatory, offensive, inflammatory, vulgar, irrelevant/off-topic, racist or obvious marketing or spam. Dr. Dobb's further reserves the right to disable the profile of any commenter participating in said activities.

Disqus Tips To upload an avatar photo, first complete your Disqus profile. | View the list of supported HTML tags you can use to style comments. | Please read our commenting policy.