BIOS

BIOS
Company type	Firmware
Industry	Computer firmware
Founded	1975
Headquarters	N/A
Products	Basic Input/Output System firmware

In the realm of computing, the BIOS (Basic Input/Output System, also referred to as the System BIOS, ROM BIOS, BIOS ROM, or PC BIOS) is firmware responsible for delivering runtime services to operating systems and software applications, as well as handling hardware initialization during the booting sequence. This firmware is embedded on the computer's motherboard at manufacturing.

The designation originates from the 1975 CP/M operating system's Basic Input/Output System. Initially, BIOS was proprietary technology exclusive to the IBM PC, but companies such as Phoenix Technologies reverse engineered it to develop compatible alternatives. This original BIOS framework evolved into a widely recognized de facto standard.

In legacy personal computers, BIOS conducts hardware initialization and verification through a power-on self-test (POST), then transfers control to a boot loader stored on mass storage devices to launch an OS kernel. During the era dominated by DOS, BIOS provided standardized interrupt calls enabling consistent access to keyboards, displays, storage units, and other I/O devices for both applications and operating systems. Contemporary OSes typically bypass these BIOS interrupts after the initial startup phase.

Most BIOS versions are customized for particular computer models or motherboards and interact closely with system chipsets. While early BIOS firmware resided on ROM chips soldered onto motherboards, it eventually transitioned to rewritable flash memory. This change facilitated easier updates for feature enhancements or bug fixes but also introduced vulnerabilities such as BIOS rootkits and risks of motherboard failure due to unsuccessful firmware updates.

The Unified Extensible Firmware Interface (UEFI) was developed as a successor to traditional PC BIOS to address its inherent technical constraints. UEFI firmware frequently includes legacy BIOS support layers to maintain compatibility with older operating systems and hardware lacking native UEFI capabilities. Since 2020, Intel-based systems have discontinued legacy BIOS support. The final Microsoft Windows release compatible with legacy BIOS is Windows 10; meanwhile, Windows 11 mandates UEFI compliance except for select IoT Enterprise editions beginning with version 24H2.

History

The acronym BIOS (Basic Input/Output System) was coined by Gary Kildall and first utilized in the 1975 CP/M operating system. It referred specifically to the machine-dependent segment of CP/M loaded during boot-up that directly interfaces with hardware components. Typically, CP/M machines contain only a minimalistic boot loader stored in ROM.

Operating systems like MS-DOS, PC DOS, and DR-DOS incorporate files named "IO.SYS", "IBMBIO.COM", "IBMBIO.SYS", or "DRBIOS.SYS"—these "DOS BIOS" files represent the lower-level, hardware-specific portion of the OS. When combined with the hardware-specific yet OS-independent "System BIOS" embedded in ROM, this structure parallels the "CP/M BIOS".

Originally exclusive to the IBM PC, BIOS was reverse engineered by firms such as Phoenix Technologies to produce compatible implementations.

With the release of IBM's PS/2 line, System BIOS was divided into two components: "CBIOS" (Compatibility BIOS), which ensured backward compatibility with DOS environments, and "ABIOS" (Advanced BIOS), which introduced enhanced interfaces supporting multitasking operating systems like OS/2.

User Interface

The initial BIOS of the IBM PC and XT lacked an interactive user interface; error notifications appeared as on-screen messages or beep codes during POST if video hardware failed to initialize. Configuration was managed through physical switches and jumpers located on the motherboard and expansion cards.

Starting in the mid-1990s, BIOS ROMs commonly incorporated a "BIOS configuration utility" (BCU) or "BIOS setup utility," accessible during startup via specific key combinations. This feature enabled users to adjust system settings through an interactive menu controlled by the keyboard, eliminating the need for manual hardware switches.

Earlier IBM-compatible machines, such as the IBM AT, stored configuration data in battery-backed RAM and relied on a bootable floppy disk containing a configuration program provided with the system; losing this disk rendered settings modification impossible. Similarly, computers equipped with an EISA bus utilized an EISA Configuration Utility (ECU).

Contemporary Wintel-based PCs provide setup interfaces akin to those found in late 1990s ROM-resident BIOS utilities, allowing hardware configuration via keyboard input and screen display. Configuration data is frequently saved in flash ROM, occasionally co-located with the BIOS firmware itself.

Extensions (Option ROMs)

Expansion cards such as hard drive host bus adapters and video cards include firmware featuring BIOS extension option ROM code, which broadens BIOS functionality. This code executes prior to the BIOS loading the operating system from mass storage, typically performing hardware tests and initialization while adding or overriding BIOS services. For example, a SCSI controller often contains a BIOS extension ROM to support attached drives. Option ROMs may also enable alternative boot methods like network booting. Adding or removing an adapter card or option ROM chip can substantially change how an IBM-compatible system operates.

The motherboard BIOS generally contains routines to initialize built-in display and storage devices. This process involves detecting and validating devices, setting base address registers, pointers, interrupt vector tables, selecting paging modes, configuring interrupts, and applying default device parameters. Plug-in cards such as SCSI, RAID, network interface cards, and video cards frequently have their own BIOS (e.g., Video BIOS) that supplements or replaces system BIOS functions. Even integrated devices may include option ROMs embedded within the motherboard BIOS.

Add-on cards require option ROMs when they lack support from the motherboard BIOS and need initialization or access to BIOS services before the operating system loads, typically during boot-up. Early PCs benefited from option ROM code running faster than system RAM; however, modern systems generally copy ("shadow") BIOS ROM code into RAM to enhance execution speed.

Physical Placement

Option ROMs are usually located on expansion cards, but early PCs such as the original IBM PC and PC XT featured an extra ROM socket on the motherboard for installing option ROMs. The four ROM chips containing the BASIC interpreter could also be replaced with custom option ROM modules. The IBM PCjr was distinctive in having two front-facing ROM cartridge slots mapped into upper memory areas reserved for option ROMs. These cartridges could hold multiple ROM modules, including option ROMs recognized by the BIOS or BASIC programs handled distinctly.

System startup

Execution begins at specific physical addresses depending on the processor model: the 8086 and 8088 CPUs start at FFFF0h; the 80286 at FFFFF0h; while the 80386 and subsequent x86 processors initiate at FFFFFFF0h. These addresses correspond to the initial instruction of the BIOS during system startup.

During a cold boot, triggered by powering on or resetting, the complete power-on self-test (POST) sequence is executed. In contrast, a warm boot (initiated by Ctrl+Alt+Delete) may skip POST if a flag in nonvolatile BIOS memory ("CMOS") indicates this. POST is responsible for detecting, testing, and initializing essential hardware components such as the CPU, chipset, RAM, motherboard, video adapter, keyboard, mouse, hard disks, optical drives, and integrated peripherals.

Early IBM PC models incorporated a POST routine that permitted downloading diagnostic programs through the keyboard port for factory-level testing.

Following POST, most BIOS implementations scan for option ROM modules—also known as BIOS extension ROMs—located in the "upper memory area" beginning at address 0xA0000. The BIOS examines memory from 0x0C0000 to 0x0F0000 in increments of 2 KB searching for a distinctive two-byte signature (0x55 0xAA). Valid option ROMs include size and entry point information; after verifying the checksum, control is handed over to the ROM's initialization routine.

These extension ROMs initialize their associated hardware devices, register necessary interrupt vectors, and may provide configuration menus or diagnostics by utilizing BIOS services or other option ROMs. Generally, after completing initialization, an option ROM returns control to the BIOS, which continues scanning for additional ROMs until all are processed. Occasionally, an option ROM might not relinquish control, thereby interrupting the BIOS boot sequence.

Boot process

Once POST and option ROM scanning are complete, the BIOS invokes interrupt 19h to commence the boot process. Programs can also trigger interrupt 19h to reboot the system but must first disable interrupts and asynchronous hardware to prevent system freezes.

When interrupt 19h is called, the BIOS searches for boot loader code on devices such as hard disk, floppy disk, CD, or DVD. It loads and executes the first valid boot loader discovered, transferring execution to it.

The order in which boot devices are checked is configurable via Nonvolatile BIOS memory (CMOS) settings or previously through physical DIP switches. The BIOS attempts to read the first sector (boot sector) from each device in sequence. If a sector cannot be read successfully, it proceeds to the next device. Some BIOS versions verify a boot sector signature (0x55 0xAA) located in the last two bytes before accepting a device as bootable.

After locating a bootable device, control is transferred without further interpretation of the boot sector beyond possible signature validation. The responsibility for parsing structures like partition tables lies with the boot loader itself.

Non-disk devices such as network adapters employ boot procedures defined by their option ROMs or through integration with motherboard BIOS ROMs; these can affect or override conventional boot operations.

With support for the El Torito specification, optical drives simulate a 3.5" floppy disk during BIOS booting. This virtual floppy contains software that facilitates access to the native format of optical media since reading a CD or DVD’s first sector differs fundamentally from reading disks.

Expansion ROMs can cooperatively influence the boot sequence by utilizing the BIOS Boot Specification (BBS) API, which allows them to register their boot capabilities and enable users to select them through the BIOS interface. Most BBS-compliant BIOS implementations restrict user interaction until all expansion ROMs have completed their registration process.

Alternatively, expansion ROMs might independently modify the boot sequence by hooking interrupt 19h or related interrupts such as 13h (disk services), thereby replacing or altering standard BIOS boot behavior. Before BBS adoption, this method was predominantly used to provide boot support for unsupported devices.

Boot sequence priority

Users have the ability to set the boot sequence within the BIOS, commonly selecting whether to start from a hard drive or removable media. Contemporary BIOS versions offer configurable boot order options, whereas earlier BIOS models featured fixed or limited priority arrangements—usually prioritizing floppy drives first, followed by hard disks, without accommodating other devices. Initial personal computers booted exclusively from the first installed floppy or hard drive.

Boot errors

In the original IBM PC and XT systems, absence of a bootable disk prompted the BIOS to invoke ROM BASIC through interrupt 18h. Since clone PCs lacked ROM BASIC, unsuccessful boots resulted in a "No ROM BASIC" error and system halt. Subsequent machines displayed messages such as "No bootable disk found" or requested disk insertion with a retry option. Today’s BIOS implementations might either suppress messages or automatically enter configuration mode upon boot failure.

Boot environment details

During startup, the CPU functions in real mode with most registers undefined except for SS, SP, CS, and DL. The bootloader is consistently loaded at physical address 0x07C00, although CS:IP values differ depending on BIOS design. The DL register contains the number identifying the boot device (used by interrupt 13h). While SS:SP is initialized, its size and location are not standardized; consequently, bootloaders generally establish their own stack.

All BIOS routines remain accessible at this early stage. The interrupt vector table occupies memory below 0x00400, while POST sets up timers, interrupt controllers, DMA controllers, and chipset components. DRAM refresh cycles are active for both conventional and extended memory regions. BIOS interrupts point to relevant service routines; some interrupts utilize placeholder handlers. System RAM between 0x00400–0x004FF is reserved for POST data; memory at 0x00500 and above is free for use by the boot program and may be overwritten as necessary.

Operating system interfaces

Each manufacturer customizes their BIOS ROM to support their hardware configuration, providing uniform low-level services—such as keyboard input reading or disk writing—for software and operating systems. For example, an IBM PC might support multiple display adapters, yet a single BIOS system call enables character output in text mode or graphics mode regardless of hardware variations.

BIOS supplies a fundamental input/output function set to manage peripherals like keyboards and displays. Under MS-DOS, these BIOS services were accessed via interrupt 13h for disk operations or other documented BIOS interrupt calls for video, keyboard, and device management.

Operating systems designed to supplant basic firmware implement their own interfaces. Starting in the 1980s, many MS-DOS applications bypassed BIOS video routines to accelerate graphics by directly programming hardware. Some developers exploited PC display adapter capabilities unsupported by IBM BIOS by avoiding it altogether. Since AT-compatible BIOS operates in Intel real mode, protected mode operating systems on 286 and later processors required protected mode device drivers to substitute BIOS services.

Modern operating systems such as Windows and Linux rely on BIOS interrupt calls primarily during startup. Prior to rendering the initial graphical interface, all input/output operations are managed through BIOS. Boot menus—like Windows’ text-based options for selecting OS versions, safe mode, or last known good configuration—are displayed and controlled via BIOS.

Many current PCs still support booting legacy operating systems such as MS-DOS or DR-DOS that depend extensively on BIOS for console and disk input/output, assuming the system firmware includes a BIOS or UEFI with Compatibility Support Module (CSM) functionality.

Processor microcode updates

Since the P6 generation, Intel processors have incorporated reprogrammable microcode. Similarly, AMD introduced microcode update capability starting with the K7 architecture. Microcode patches addressing processor faults are delivered through BIOS updates; because microcode is loaded into the processor's SRAM, these updates must be applied every time the system boots. Without this functionality, replacing processors due to bugs would be unavoidable—for instance, Intel’s Pentium FDIV bug caused costly recalls because microcode could not be revised. Additionally, operating systems have the ability to apply microcode updates.

Identification

Certain BIOS implementations include a Software Licensing Description Table (SLIC), a digital signature embedded by the original equipment manufacturer (OEM), such as Dell. This SLIC is stored within the ACPI data tables and contains no executable code.

OEMs distributing Microsoft Windows and related application software utilize the SLIC to validate licensing for OEM Windows installations and system recovery disc media. Systems equipped with a SLIC can be preactivated with an OEM product key by verifying an XML-formatted OEM certificate against the BIOS SLIC, enabling automatic activation (refer to System Locked Preinstallation, SLP). For clean Windows installations, both the OEM key (SLP or COA) and a matching digital certificate corresponding to the BIOS SLIC are required to bypass activation prompts. Typically, this is accomplished using OEM-provided recovery images; experienced users may extract certificate files and decode product keys to manually perform SLP activation.

Overclocking

Certain BIOS versions provide overclocking options, permitting CPUs to operate at frequencies exceeding their official specifications. While this can boost performance, it carries risks such as reduced system stability if cooling solutions are insufficient and may decrease hardware longevity. Incorrect overclocking settings can lead to rapid overheating and potential damage to components.

Modern use

Legacy operating systems like MS-DOS rely heavily on BIOS for input/output operations. However, in protected and long mode environments typical of modern multitasking operating systems, direct BIOS calls are inefficient and generally avoided after initial boot stages.

During the 1990s, BIOS introduced protected mode interfaces supporting systems like Microsoft Windows and Unix variants, including features such as Advanced Power Management (APM), Plug and Play BIOS, Desktop Management Interface (DMI), VESA BIOS Extensions (VBE), e820 memory mapping, and MultiProcessor Specification (MPS). Since 2000, most BIOS implementations have incorporated Advanced Configuration and Power Interface (ACPI), SMBIOS, VBE, and e820 support to meet contemporary OS demands.

Following OS loading, System Management Mode code continues execution within SMRAM. Since around 2010, BIOS technology has progressively shifted towards UEFI standards to improve system initialization processes and enhance security.

Setup utility

Early IBM PC and XT models lacked user-friendly interfaces for BIOS configuration; instead, users adjusted settings via physical DIP switches on the motherboard. Subsequent IBM-compatible systems featuring 80286 processors employed battery-backed nonvolatile BIOS memory (CMOS RAM) to store configuration details such as video adapter type, memory capacity, and hard drive parameters. These settings were modified using disk-based utilities rather than firmware-resident software, often requiring a "reference diskette," as seen on machines like the IBM Personal Computer/AT.

Initial BIOS designs did not support passwords or boot device selection; they defaulted to booting from the first floppy drive or hard disk. Security depended on a mechanical keylock switch that was easily circumvented by opening the computer case.

With the advent of 386-class machines, BIOS setup utilities became embedded within ROM firmware and could be accessed by pressing designated keys during startup to configure system parameters prior to loading the operating system.

Contemporary BIOS setup interfaces offer either a text user interface (TUI) or a graphical user interface (GUI). Access is typically granted via keys such as Delete (common among Acer, Asus, Gigabyte, MSI), F2 (Dell and Lenovo laptops), F1 (Lenovo desktops), or F10 (HP). A prompt indicating how to enter setup usually appears briefly during boot.

Common features found in modern BIOS setup utilities include:

Enabling or disabling hardware components
Adjusting the system time
Configuring boot device priority
Setting passwords to protect BIOS access and prevent unauthorized booting from removable storage devices

Hardware Monitoring

Contemporary BIOS configurations frequently feature a PC Health Status or Hardware Monitoring section that communicates with a dedicated Hardware Monitor chip located on the motherboard. This functionality allows for tracking of temperatures within the CPU and chassis, monitoring power supply voltages, and measuring fan rotational speeds.

Once the system boots, the Hardware Monitor chip generally takes over the tasks of hardware surveillance and fan regulation. This chip may either be a standalone unit connected via I²C or SMBus, or integrated within a Super I/O controller interfaced through ISA or LPC buses. Certain operating systems, including NetBSD with its envsys framework and OpenBSD utilizing sysctl hw.sensors, natively support these hardware monitoring components.

In some implementations, the BIOS exposes hardware monitoring information through ACPI, enabling the operating system to access sensor data using ACPI protocols.

BIOS Reprogramming

On modern personal computers, the BIOS firmware resides in rewritable memory such as EEPROM or NOR flash memory, allowing updates commonly referred to as flashing. This update process is typically conducted using software supplied by the hardware manufacturer or initiated during POST from a BIOS image stored on removable media like USB drives or hard disks. Flashing serves to correct firmware bugs, enhance system performance, or add support for new hardware components. Certain platforms also permit BIOS updates via floppy disks or dedicated partitions on hard drives.

Hardware

The original IBM PC BIOS was contained within mask-programmed read-only memory (ROM) chips soldered onto the motherboard. Although these ROMs could be physically replaced, they were not designed for user modification. To facilitate easier updates, many IBM PC compatible systems adopted reprogrammable memory technologies such as EPROM, EEPROM, and eventually flash memory—commonly NOR flash. According to Robert Braver, president of Micro Firmware (a BIOS manufacturer), Flash BIOS chips became widespread around 1995 because EEPROMs provided a more cost-effective and simpler programming process compared to EPROMs. Unlike EPROMs which required removal from the circuit for reprogramming, flash memory chips could be updated while still installed on the motherboard. These BIOS upgrades allowed for improved hardware compatibility and bug fixes.

Beginning with the IBM AT model, computers incorporated a hardware clock adjustable via BIOS settings, including a century bit designed to manage the transition into the year 2000. From approximately 1995 onward, most BIOS versions supported automatic century bit adjustments to ensure Y2K compliance.

Initially, flash memory chips interfaced through the ISA bus. Starting in 1998, BIOS flashing migrated to the LPC bus under the "firmware hub" (FWH) specification, before transitioning again in 2005 to use the SPI bus.

Over time, both BIOS firmware size and storage capacity have expanded dramatically; contemporary BIOS images can reach up to 32 megabytes in size compared to the original 8 KB mask ROMs. Some modern motherboards now incorporate larger NAND flash memory integrated circuits capable of hosting complete compact operating systems—for instance, certain ASUS laptops include embedded versions of Splashtop OS. The concept of integrating an operating system with BIOS traces back to the 1980s when Microsoft offered MS-DOS stored in ROM for some PC clones like the Tandy 1000 HX.

Early IBM PC AT models featured a microcontroller-based keyboard interface equipped with programmable memory often implemented via EPROM. This controller was also responsible for managing the A20 gate, which controls access to memory above one megabyte; firmware updates sometimes enhanced compatibility with software relying on upper memory areas.

BIOS firmware may include modules such as the Memory Reference Code (MRC), which handles memory initialization tasks including reading from SPD devices and setting timing parameters.

Modern BIOS implementations often integrate additional firmware components like the Intel Management Engine or the AMD Platform Security Processor.

Vendors and products

BIOS implementations comparison
Company	AwardBIOS	AMIBIOS	Insyde	SeaBIOS
License	Template:Proprietary	Template:Proprietary	Template:Proprietary	Template:Open source
Development status	Template:Terminated	Template:Terminated	Template:Terminated	Yes
32-bit PCI BIOS support	Yes	Yes	Yes	Yes
AHCI support	Yes	Yes	Yes	Yes
APM support	Yes	Yes	Yes (version 1.2)	Yes (version 1.2)
BBS compliance	Yes	Yes	Yes	Yes
Boot menu availability	Yes	Yes	Yes	Yes
Compression method	Yes (uses LHA)	Yes (LHA)	Yes (RLE)	Yes (LZMA)
CMOS support	Yes	Yes	Yes	Yes
EDD support	Yes	Yes	Yes	Yes
ESCD support	Yes	Yes	Unknown	No
Flash update from ROM capability	Unknown	Yes	Unknown	No

|- ! Programming language used

| Assembly language
| Assembly language
| Assembly language
| C

|- ! LBA (Logical Block Addressing) support

| Yes (48-bit)
| Yes (48-bit)
| Yes
| Yes (48-bit)

|- ! Multiprocessor Specification compliance

| Yes
| Yes
| Yes
| Yes

|- ! Option ROM support

| Yes
| Yes
| Yes
| Yes

|- ! Password protection feature

| Yes
| Yes
| Yes
| No

|- ! PMM (Post Memory Manager) presence

| Unknown
| Yes
| Unknown
| Yes

|- ! Setup interface availability

| Yes 
| Yes 
| Yes 
| No

|- ! SMBIOS (System Management BIOS) support

| Yes 
| Yes 
| Yes 
| Yes

|- ! Splash screen format support

| Yes (EPA format) 
| Yes (PCX format)  
| Yes  
| Yes (BMP, JPG formats)

|- ! TPM (Trusted Platform Module) support

| Unknown  
| Yes  
| Unknown  
| Partial

|- ! USB boot capability

| Yes  
| Yes  
| Yes 
| Yes

|- ! USB hub support

| Unknown  
| Unknown  
| Unknown  
| Yes

|- ! USB keyboard compatibility

| Yes  
| Yes  
| Yes  
| Yes

|- ! USB mouse compatibility

| Yes  
| Yes  
| Yes  
| Yes

|} IBM provided BIOS source code for its initial PC models in the IBM PC Technical Reference Manual, offering detailed insight into fundamental BIOS operations.

In May of 1984, Phoenix Technologies introduced its inaugural ROM-BIOS, which allowed original equipment manufacturers to create IBM PC-compatible systems without needing to reverse-engineer the BIOS code. This development significantly propelled the expansion of the PC-compatible marketplace and boosted DOS adoption. The first BIOS from American Megatrends (AMI) appeared in 1986.

Documentation for many new BIOS specifications is often incomplete or unavailable publicly, restricting understanding of proprietary BIOS enhancements beyond IBM’s original design.

Numerous motherboard producers obtain BIOS cores through licensing agreements with independent BIOS vendors (IBVs) such as American Megatrends, Insyde Software, and Phoenix Technologies, tailoring firmware to their specific hardware platforms. As a result, firmware updates are mainly distributed by the motherboard manufacturers themselves. During the late 1990s, Phoenix acquired Award Software and Byosoft, gradually retiring the Award brand while still acknowledging it in newer BIOS versions. Additionally, Phoenix acquired General Software in 2007, a company specializing in BIOS solutions for embedded Intel-based devices.

SeaBIOS represents a fully open-source BIOS option that is actively maintained and developed.

Open-source BIOS alternatives

The open-source sector has increased its initiatives to create substitutes for proprietary BIOS firmware. One of the earliest open standards for boot firmware was Open Firmware, which received initial approval from IEEE as IEEE 1275-1994 but was later rescinded in 2005. Subsequent developments include projects such as OpenBIOS, coreboot, and libreboot. AMD has released chipset specifications compatible with coreboot, and Google actively supports this initiative. Additionally, Tyan, a manufacturer of motherboards, provides coreboot alongside conventional BIOS on their Opteron-based boards.

Security

The presence of EEPROM and flash memory technologies enables BIOS updates by users, allowing manufacturers to distribute firmware improvements that enhance compatibility and resolve bugs. To safeguard against update failures, modern BIOS implementations incorporate a "boot block," a protected area that validates the main BIOS before execution. Should corruption be detected, the system prompts recovery through external media. Certain motherboards include a backup BIOS feature (often called DualBIOS) to restore functionality after firmware corruption.

At least five distinct BIOS-targeting malware strains have been identified, including Mebromi, which affected users primarily in China. The earliest BIOS virus, known as BIOS Meningitis, infected chips but caused limited harm. The second notable example was the CIH virus ("Chernobyl Virus") active in 1999; it was capable of erasing the flash ROM BIOS on Intel i430TX chipsets, resulting in unbootable systems that required manual chip reprogramming.

Modern hardware is generally resistant to CIH due to the variety of chipsets in use, protected boot blocks, and designs featuring multiple BIOS chips. Current operating systems such as Windows XP, Linux, and macOS employ hardware abstraction layers that block direct hardware access by user-mode applications, thereby lowering susceptibility.

Although other BIOS malware remains feasible, many Windows users operate programs with administrative rights, which can enable malware to interact with hardware without exploiting vulnerabilities. Operating systems like OpenBSD and Linux distributions patched with grsecurity impose stricter access controls, necessitating more sophisticated attacks.

A third method of BIOS compromise was presented in 2006 by John Heasman at Black Hat, demonstrating privilege escalation through malicious ACPI code stored in flash memory. A fourth technique, termed "Persistent BIOS infection," was disclosed in 2009 by researchers Anibal Sacco and Alfredo Ortega; this method injects malicious instructions into BIOS decompression routines, granting near-complete control during system startup. This attack requires either physical machine access or root-level permissions but underscores significant security concerns.

The Mebromi trojan specifically targets AwardBIOS systems running Windows alongside certain Chinese antivirus programs, installing a rootkit that infects the Master Boot Record.

In 2013, the US National Security Agency reported preventing a foreign state-sponsored BIOS attack aimed at financial institutions; anonymous sources implicated China as the perpetrator. Nevertheless, investigative journalism has cast doubt on these assertions.

More recent Intel platforms incorporate Intel Boot Guard (IBG), which authenticates the BIOS digital signature during boot using a public key embedded within the Platform Controller Hub (PCH). This mechanism cannot be disabled by end users and strengthens firmware security substantially.

Alternatives and successors

The Unified Extensible Firmware Interface (UEFI) acts as an enhancement to BIOS in a wide range of modern devices. Initially created for the Intel Itanium architecture, UEFI has since expanded its compatibility to include x86 and Arm systems. The development and specification of UEFI are managed by the Unified EFI Forum, a collective of industry stakeholders. EFI boot support is integrated into Microsoft Windows editions utilizing the GPT, the Linux kernel from version 2.6.1 onward, as well as macOS on Intel-based Mac computers. Currently, most contemporary PC models come equipped with UEFI firmware. Nevertheless, UEFI's security measures against rootkits can limit modifications by user-installed software, which has sparked debate within the open hardware community regarding its adoption as a BIOS substitute. Significantly, Windows 11 mandates UEFI for system startup,^[1] except in the case of IoT Enterprise versions.^[2] Furthermore, UEFI has been a requirement for devices shipped with Windows 8^[3]^[4] and subsequent versions.

With the emergence of UEFI throughout the 2010s, traditional BIOS systems that relied on BIOS interrupt calls were rebranded as "legacy BIOS."

Within x86 environments, alternatives to legacy BIOS include projects such as coreboot and libreboot.

Certain servers and professional workstations employ platform-independent firmware known as Open Firmware (IEEE-1275), which is based on the Forth programming language. This firmware is standard on Sun's SPARC machines, IBM's RS/6000, various PowerPC architectures like the CHRP, and also on x86-based devices such as the OLPC XO-1.

By around 2015, Apple discontinued legacy BIOS support within UEFI on Intel-based Mac computers, removing options for legacy mode operation.

In 2017, Intel revealed intentions to phase out legacy BIOS support by 2020; since 2019, OEM PCs built on Intel platforms no longer provide legacy BIOS functionality.^[5]

External links

BIOS Boot Specification 1.01 (archived)
How BIOS Works
Implementing a Plug and Play BIOS Using Intel's Boot Block Flash Memory (archived)
List of BIOS options (archived)
Persistent BIOS Infection (archived)
Preventing BIOS Failures Using Intel Boot Block Flash Memory (archived)

↑ Lua error in Module:Citation/CS1/Configuration at line 2123: attempt to index field '?' (a nil value).
↑ Cite error: Invalid <ref> tag; no text was provided for refs named 11_IoT_req
↑ Lua error in Module:Citation/CS1/Configuration at line 2123: attempt to index field '?' (a nil value).
↑ Lua error in Module:Citation/CS1/Configuration at line 2123: attempt to index field '?' (a nil value).
↑ Lua error in Module:Citation/CS1/Configuration at line 2123: attempt to index field '?' (a nil value).

[1] Lua error in Module:Citation/CS1/Configuration at line 2123: attempt to index field '?' (a nil value).

[11_IoT_req-2] Cite error: Invalid <ref> tag; no text was provided for refs named 11_IoT_req

[3] Lua error in Module:Citation/CS1/Configuration at line 2123: attempt to index field '?' (a nil value).

[4] Lua error in Module:Citation/CS1/Configuration at line 2123: attempt to index field '?' (a nil value).

[5] Lua error in Module:Citation/CS1/Configuration at line 2123: attempt to index field '?' (a nil value).

[1]

[2]

[3]

[4]

[5]