• <More on Intel.com

EFI Capsule Specification v0.9

We are sorry, This PDF is available in download format only

EFI Capsule Specification v0.9
This document describes the process by which data can be passed from runtime (operating system [OS]–present) applications back to the preboot phases (Pre-EFI Initialization [PEI], Driver Execution Environment [DXE], and Boot Device Selection [BDS]) in an implementation of the Intel® Platform Innovation Framework for EFI (hereafter referred to “the Framework”), using a formatted variable-length data structure known as a capsule. Capsules were designed for and are intended to be the major vehicle for delivering firmware volume changes. There is no requirement that capsules be limited to that function.
In many ways, the design of capsules builds on, and can be considered an extension of, the firmware volume design. The format of the capsule is very similar to the format of a firmware volume, allowing the same tools to create both formats and the same (or slightly upgraded versions of the same) protocols to manipulate both. This document does not describe the mechanism for modifying system variables. These mechanisms are described in various EFI specifications. Capsules are, however, a mechanism by which variables that are specific to a single firmware volume (for example, policy data concerning an add-in device) can be manipulated.
Goals: The capsule mechanism was designed with the following goals:
• Generic Solution: Capsules provide a generic mechanism for transitioning data from the OS to the boot mechanism. While an update is the main target of capsules, other functionality may be implemented, particularly by passing drivers as part of the capsule.
• Commonality: The mechanism should be able to support all firmware devices from all vendors whose firmware is compliant with the requirements of the mechanism, thus providing a common means to update platforms over systems running Framework-based firmware.
• Security: Capsules allow the levels of security for the update to be tuned to the security requirements of the system.
• Abstraction: The various components do not have to be aware of each other’s implementations. For example, an OS-present update application should not have to be aware of the technologies that are used to implement the firmware devices.
• Distribution control: Various types of systems have various support models. The mechanism should allow control over who decides what updates are allowed.
• OS-Present Update: The user should be able to perform the job of requesting the update in the user’s most familiar environment.
Read the full EFI Capsule Specification.