Extensible Firmware Interface Specification
4 12/12/00 Version 1.02
• Abstraction of the OS from the firmware. The specification defines interfaces to platform
capabilities. Through the use of abstract interfaces, the specification allows the OS loader to be
constructed with far less knowledge of the platform and firmware that underlie those interfaces.
The interfaces represent a well-defined and stable boundary between the underlying platform
and firmware implementation and the OS loader. Such a boundary allows the underlying
firmware and the OS loader to change provided both limit their interactions to the defined
interfaces.
• Reasonable device abstraction free of legacy interfaces. “PC-AT” BIOS interfaces require the
OS loader to have specific knowledge of the workings of certain hardware devices. This
specification provides OS loader developers with something different — abstract interfaces that
make it possible to build code that works on a range of underlying hardware devices without
having explicit knowledge of the specifics for each device in the range.
• Architecturally shareable system partition. Initiatives to expand platform capabilities and add
new devices often require software support. In many cases, when these platform innovations
are activated before the OS takes control of the platform, they must be supported by code that is
specific to the platform rather than to the customer’s choice of OS. The traditional approach to
this problem has been to embed code in the platform during manufacturing (for example, in
flash memory devices). Demand for such persistent storage is increasing at a rapid rate. This
specification defines persistent store on large mass storage media types for use by platform
support code extensions to supplement the traditional approach. The definition of how this
works is made clear in the specification to ensure that firmware developers, OEMs, operating
system vendors, and perhaps even third parties can share the space safely while adding to
platform capability.
Defining a boot environment that delivers these attributes could be accomplished in many ways.
Indeed several alternatives, perhaps viable from an academic point of view, already existed at the
time this specification was written. These alternatives, however, typically presented high barriers
to entry given the current infrastructure capabilities surrounding Intel architecture platforms. This
specification is intended to deliver the attributes listed above while also recognizing the unique
needs of an industry that has considerable investment in compatibility and a large installed base of
systems that cannot be abandoned summarily. These needs drive the requirements for the
additional attributes embodied in this specification:
• Evolutionary, not revolutionary. The interfaces and structures in the specification are designed
to reduce the burden of an initial implementation as much as possible. While care has been
taken to ensure that appropriate abstractions are maintained in the interfaces themselves, the
design also ensures that reuse of BIOS code to implement the interfaces is possible with a
minimum of additional coding effort. In other words, on IA-32 platforms the specification can
be implemented initially as a thin interface layer over an underlying implementation based on
existing code. At the same time, introduction of the abstract interfaces provides for migration
away from legacy code in the future. Once the abstraction is established as the means for the
firmware and OS loader to interact during boot, developers are free to replace legacy code
underneath the abstract interfaces at leisure. A similar migration for hardware legacy is also
possible. Since the abstractions hide the specifics of devices, it is possible to remove
underlying hardware, and replace it with new hardware that provides improved functionality,
reduced cost, or both. Clearly this requires that new platform firmware be written to support
the device and present it to the OS loader via the abstract interfaces. However, without the
interface abstraction, removal of the legacy device might not be possible at all.