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.
228KB
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.
