PIWG and USWG

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.