Firmware, BIOS, and UEFI
Firmware is software stored with hardware that prepares a computer to run. BIOS is the older PC firmware interface, while UEFI is its modern successor with defined boot services, variables, executable formats, and security features.
itComputer architecture and hardware | OpenSkills.info
Course pathWalk it in order
Look it upDip in anytime
Go furtherLeaves this page
Intro
Firmware, BIOS, and UEFI
Firmware is software that starts before the operating system and establishes the machine state that later software depends on. It runs from nonvolatile storage associated with the platform or a device. On a PC, platform firmware initializes processors, memory, chipsets, and selected devices. It then chooses the next executable in the boot chain.
BIOS and UEFI describe two different firmware interfaces. The original PC BIOS exposes 16-bit services and historically starts boot code from a selected device. UEFI defines data structures, executable images, protocols, variables, boot services, and runtime services. Modern setup screens may still be labeled “BIOS” even when the implementation is UEFI.
Firmware is broader than either term. A storage controller, network adapter, embedded controller, or management controller can run its own firmware. This course concentrates on PC platform firmware and the handoff to an operating-system loader.
The startup path
power or reset
↓
processor reset vector and immutable or protected startup code
↓
early silicon and memory initialization
↓
device discovery and platform configuration
↓
firmware boot manager
↓
EFI application or legacy boot code
↓
operating-system loader
The processor begins at an architecture-defined reset state. Platform-specific code establishes enough execution context to continue. Memory is not necessarily usable at first, so early firmware works within severe resource constraints. Later phases initialize DRAM, enumerate buses, publish hardware-description tables, and prepare interfaces for the operating system.
The UEFI Platform Initialization specification describes a common phase model. The Security phase begins from reset. Pre-EFI Initialization establishes temporary execution resources and memory. The Driver Execution Environment initializes the platform and dispatches drivers. Boot Device Selection applies boot policy and reaches a UEFI boot option. Implementations can differ internally while still presenting the UEFI interface at the operating-system boundary.
Continue the course
This section is part of the paid course.
See pricing to subscribe, or log in if you already have access.
Where this skill leads
Relevant careers
See how this topic contributes to broader role-level skill maps.
Sources
- https://uefi.org/specs/UEFI/2.11/01_Introduction.html
Supports
- UEFI succeeds EFI 1.10 as a firmware-to-operating-system interface
- UEFI specifies interfaces and data structures rather than one mandatory internal implementation
- https://uefi.org/specs/UEFI/2.11/02_Overview.html
Supports
- The UEFI firmware core exposes a system table, boot services, runtime services, protocols, and image services
- UEFI applications and operating-system loaders are executable images started by firmware
- https://uefi.org/specs/UEFI/2.11/03_Boot_Manager.html
Supports
- BootOrder and Boot-number variables express firmware boot policy
- Boot options contain descriptions and device paths
- Removable media can use architecture-specific fallback filenames under EFI slash BOOT
- https://uefi.org/specs/UEFI/2.11/07_Services_Boot_Services.html
Supports
- Boot services include memory, protocol, and image operations used before the operating-system handoff
- ExitBootServices requires the current memory-map key and ends boot-service availability
- https://uefi.org/specs/UEFI/2.11/08_Services_Runtime_Services.html
Supports
- Runtime services include variable, time, capsule, and reset interfaces
- Runtime-service support after handoff is smaller than the boot-service environment
- https://uefi.org/specs/UEFI/2.11/13_Protocols_Media_Access.html
Supports
- UEFI defines file-system and media protocols used to reach EFI applications
- The EFI System Partition provides a standard file-system location for EFI images
- https://uefi.org/specs/UEFI/2.11/32_Secure_Boot_and_Driver_Signing.html
Supports
- Secure Boot authenticates executable images against configured trust data
- Platform Key, Key Exchange Keys, allowed data, and forbidden data have distinct policy roles
- Secure Boot image authorization is not disk encryption or ordinary application validation
- https://uefi.org/specs/PI/1.8A/V1_Overview.html
Supports
- Platform Initialization describes SEC, PEI, DXE, and BDS phases
- Early phases establish temporary resources and permanent memory before driver execution and boot policy
- https://learn.microsoft.com/en-us/windows-hardware/design/device-experiences/oem-uefi
Supports
- Platform firmware controls startup before handing control to Windows or another operating system
- UEFI replaces the older BIOS firmware interface and EFI 1.10
- UEFI supports disks larger than two terabytes and more than four partitions in modern Windows platform designs
- https://learn.microsoft.com/en-us/windows-hardware/drivers/bringup/secure-boot
Supports
- Secure Boot verifies pre-operating-system software against platform trust policy
- Windows 8 certification brought Secure Boot requirements into mainstream PC deployment
- https://learn.microsoft.com/en-us/windows/security/information-protection/secure-the-windows-10-boot-process
Supports
- Secure Boot blocks untrusted startup components while measured boot records startup measurements
- Secure Boot, Trusted Boot, measured boot, and disk encryption address different boundaries
- https://learn.microsoft.com/en-us/windows-hardware/drivers/bringup/windows-uefi-firmware-update-platform
Supports
- Windows defines an UpdateCapsule-based system-firmware delivery path
- Update packages and platform firmware have separate responsibilities in applying an update
- https://fwupd.github.io/libfwupdplugin/uefi-capsule-README.html
Supports
- fwupd can use the UEFI UpdateCapsule interface to stage supported system-firmware updates
- Platform support and the existing firmware participate in capsule processing
- https://doc.coreboot.org/
Supports
- coreboot initializes hardware and passes control to a payload
- Payload choices include SeaBIOS and EDK II for different firmware interfaces
- https://doc.coreboot.org/getting_started/architecture.html
Supports
- coreboot uses bootblock, romstage, ramstage, and payload stages
- Early execution can use cache as RAM before DRAM initialization
- ramstage initializes devices, publishes tables, and applies firmware locks
- https://doc.coreboot.org/getting_started/faq.html
Supports
- coreboot support remains board-specific
- coreboot and UEFI are different concepts, and a payload can supply later boot services
- Open platform firmware can retain dependencies on vendor-provided components
- https://doc.coreboot.org/mainboard/index.html
Supports
- Supported mainboards require explicit ports and board-specific documentation
- A shared processor does not establish firmware support for every board
- https://doc.coreboot.org/payloads.html
Supports
- SeaBIOS supplies legacy BIOS behavior as a payload
- EDK II can provide a UEFI environment as a payload
- https://www.tianocore.org/tianocore-wiki.github.io/reference/specs-standards/edk_ii_documentation.html
Supports
- EDK II is a development environment for UEFI and Platform Initialization modules, applications, drivers, and firmware images
- EDK II documentation covers building, driver development, Secure Boot, and platform design
- https://docs.u-boot-project.org/en/latest/develop/uefi/uefi.html
Supports
- U-Boot can expose UEFI boot and runtime services after platform initialization
- U-Boot's UEFI subsystem can load UEFI applications and operating-system loaders
- https://www.seabios.org/
Supports
- SeaBIOS is an open-source implementation of 16-bit x86 BIOS services
- SeaBIOS can run with coreboot or as virtual-machine firmware
- https://github.com/sindresorhus/awesome
Supports
- The Awesome catalog was used as the required starting point for focused ecosystem discovery
- Its security and hardware listings lead to narrower curated lists
- https://github.com/PreOS-Security/awesome-firmware-security
Supports
- The fetched Awesome Firmware Security list focuses on platform firmware security and testing
- The list identifies CHIPSEC, UEFITool, flash tools, and firmware-analysis projects as relevant ecosystem resources
- The list distinguishes firmware technologies, independent firmware vendors, and analysis tools
- https://chipsec.github.io/
Supports
- CHIPSEC assesses platform security, firmware, hardware protections, and configuration
- CHIPSEC warns against use on production end-user systems because its low-level access can reduce protections or crash a platform
- https://github.com/LongSoft/UEFITool
Supports
- UEFITool parses UEFI Platform Initialization images into structured volumes, files, and sections
- UEFITool provides graphical inspection while related commands support extraction and search
- https://flashrom.org/
Supports
- flashrom identifies, reads, verifies, erases, and writes supported flash chips
- flashrom supports internal and external programmers and warns about platform-specific damage risk
- https://github.com/ReFirmLabs/binwalk
Supports
- Binwalk analyzes firmware images for embedded files, executable code, compressed data, and file systems
- Binwalk supports offline extraction and analysis beyond UEFI-specific image layouts
- https://github.com/theopolis/uefi-firmware-parser
Supports
- uefi-firmware-parser parses and extracts UEFI volumes, file systems, files, and related structures
- Its command-line and Python interfaces support repeatable scripted analysis
- https://www.ami.com/products/aptio-v/
Supports
- Aptio V is commercial modular BIOS and UEFI firmware for client, server, embedded, and other platform designs
- Aptio V integrates UEFI, EDK II, ACPI, and PI specifications across x86 and Arm platforms
- https://www.insyde.com/sites/default/files/downloads/InsydeH2O-Embedded.pdf
Supports
- InsydeH2O is a commercial UEFI firmware framework for embedded and other system designs
- It spans the hardware-to-operating-system firmware boundary supplied to system manufacturers
- https://phoenixtech.com/phoenix-securecore/
Supports
- Phoenix SecureCore is commercial UEFI platform firmware for client and embedded systems
- It provides EDK II-based initialization, setup, Secure Boot, and update capabilities to system vendors
- https://docs.dasharo.com/
Supports
- Dasharo is an open-source firmware distribution built around board-specific platform support
- Dasharo documents UEFI, Secure Boot, update, and validation behavior for supported hardware
- https://uefi.org/sites/default/files/resources/S2_ChainOfTrust_UEFILinuxCon_FINAL_Aug.%2021.pdf
Supports
- Intel began EFI as the Intel Boot Initiative in 1998
- UEFI 2.1 added cryptography, network authentication, and Human Interface Infrastructure
- The Forum's history associates UEFI 2.2 with Secure Boot work
- https://uefi.org/press-release/UEFI_Forum_to_Manage_Key_Firmware_to_Operating_System_Specification_July_25_2005
Supports
- Industry members formed the UEFI Forum on July 25 2005
- The Forum assumed responsibility for evolving Intel EFI 1.10
- https://uefi.org/specs/UEFI/2.10/Frontmatter/Revision_History.html
Supports
- UEFI 2.3.1 work in April 2011 included Secure Boot variables
- UEFI 2.4 in April 2013 added random-number and certificate-revocation capabilities
- UEFI 2.5 in 2015 added HTTP Boot, update-resource, and persistent-memory work
- UEFI 2.8 in March 2019 added REST, Redfish discovery, JSON capsule, and memory-cryptography features
- https://uefi.org/sites/default/files/resources/UPFS11_P2_SecureBoot_Insyde.pdf
Supports
- UEFI 2.3.1 documented the deployed Secure Boot path and policy variables in 2011
- https://uefi.org/press-release/uefi-forum-launches-non-volatile-memory-and-boot-http-support-across-three
Supports
- The UEFI Forum released UEFI 2.5 on April 30 2015
- UEFI 2.5 added HTTP Boot and coordinated nonvolatile-memory and firmware-management capabilities
- https://uefi.org/press-release/industry-standard-firmware-takes-step-forward-new-uefi-forum-specification
Supports
- The UEFI Forum announced UEFI 2.8 in 2019
- UEFI 2.8 added REST and memory-cryptography support
