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
Don't Panic
Don't Panic - Firmware, BIOS, and UEFI
Firmware is software that starts before the operating system and establishes the machine state later software depends on. It runs from nonvolatile storage on the platform or a device. On a PC, platform firmware initializes processors, memory, chipsets, and selected devices, then chooses the next executable in the boot chain.
BIOS and UEFI describe two firmware interfaces. Classic 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 label: controllers and management engines run their own firmware too. This course concentrates on PC platform firmware and the handoff to an operating-system loader.
The startup path runs from power or reset through protected startup code, hardware initialization, and a boot policy that selects a loader. UEFI boot entries and variables persist across OS reinstalls. Secure Boot adds signature checks on boot components and also creates a recovery and key-management problem when enrollment is incomplete.
A working mental model separates interface (BIOS versus UEFI), implementation (vendor firmware or an open reference stack), and device firmware that the OS patch process may never touch. Misnaming the mode, ignoring variables, or forgetting device firmware leaves trust holes below the kernel.
Read the Intro for the startup path and Secure Boot rules. Use the Cheatsheet when you need the boot and variable maps. Landscape and Timeline place firmware among related platform technologies.
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