Fact-checked by Grok 2 weeks ago

Bootloader

A bootloader (also known as a bootstrap loader) is a small software embedded in a computer's or storage that initializes , locates and loads the operating system into main , and transfers control to it to begin execution during system startup. It serves as the critical intermediary between the initial power-on state and the full operation of the device, ensuring that essential components like the CPU, , and peripherals are prepared for the operating system. In the boot process, the bootloader is typically invoked by the system's , such as or on personal computers, which performs a (POST) before handing off control. Once loaded by the , the bootloader locates and loads the image along with any necessary parameters into memory, then transfers control to the kernel's . This process is essential for both general-purpose systems and devices, where bootloaders may also handle tasks like updates or multi-OS selection. Bootloaders vary in complexity and can be single-stage, residing entirely in the , or multi-stage for enhanced functionality, such as supporting multiple operating systems or secure boot mechanisms. Prominent examples include for distributions, which provides a menu-driven interface for selection; (bootmgr) in modern Windows versions, which manages boot configuration data (BCD); and U-Boot, widely used in embedded systems for initializing on -based platforms. These implementations ensure compatibility with diverse hardware architectures.

Fundamentals

Definition and Purpose

A bootloader is a small stored in (ROM), firmware such as , or a that executes immediately after a device's power-on or reset sequence to load the operating system (OS) kernel or another program into memory and transfer control to it. The primary purpose of a bootloader is to initialize essential components, load the OS into main , pass necessary parameters such as maps and boot device information to the OS, and perform basic error checking to ensure a successful handover before the OS assumes full control. This process bridges the gap between the low-level startup and higher-level OS operations, enabling the system to transition from a powered-off state to a fully operational . Bootloaders originated in early systems to connect routines with the OS, with a notable example being the (MBR) introduced in 1983 alongside 2.0 for disk-based on personal computers. Key characteristics include their compact size—often limited to under 512 bytes for implementations to fit within constraints—their self-contained nature as standalone applications without external dependencies, and their platform-specific design to interface directly with environments. For instance, in x86 systems, bootloaders interact with or to locate and load the during the initial boot stages.

Overview of the Boot Process

The boot process of a computer system begins immediately upon power-on, when the () starts execution at its predefined , a fixed that points to the initial code stored in non-volatile (). This , which may implement either legacy Basic Input/Output System () or modern Unified Extensible Firmware Interface (UEFI) standards, initializes essential hardware components and performs the () to verify the integrity of critical system elements such as the , , and basic peripherals. The phase ensures that the hardware is operational before proceeding, detecting and reporting any fundamental failures that could prevent further initialization. Following successful POST completion, the firmware consults its configured boot order—typically stored in non-volatile random-access memory (NVRAM) variables for UEFI systems—to select the primary boot device, such as a hard disk drive, solid-state drive, or optical media. It then loads the bootloader from a designated location on that device, often the master boot record (MBR) for BIOS or the EFI System Partition for UEFI, and transfers control to the bootloader code. This handoff positions the bootloader as the bridge between firmware and the operating system, receiving a minimal execution environment including the EFI System Table (in UEFI) that provides access to boot services and runtime protocols. Once active, the bootloader locates and loads the operating system into system memory, verifying its integrity through mechanisms such as calculations to detect corruption during transfer. After successful loading, the bootloader invokes the entry point and hands off control, at which point the initializes device drivers, mounts the filesystem, and starts the operating system's process to complete system startup. Throughout this sequence, error handling is integral; for instance, if no valid device is found or accessible, the or bootloader issues diagnostics like "no bootable device" errors, potentially retrying alternate devices or entering a recovery mode based on predefined variables. For the bootloader to execute reliably, certain prerequisites must be met, including the presence of in non-volatile storage locations like chips or boot sectors on persistent , and minimal readiness such as a functional CPU that reliably directs to the . These elements ensure a secure and predictable transition from to software , independent of specific platform architectures.

Bootloader Stages

Primary Bootloader

The primary bootloader represents the first executable code segment invoked directly by the system's following (POST), serving as the foundational stage in the boot sequence. It is typically stored in a fixed location such as the of non-volatile (e.g., the on hard disks) or ROM on the . This stage's core functionality involves minimal operations to load the secondary bootloader from the storage medium, often by reading subsequent sectors into and transferring control via a jump . In standard BIOS-based systems, it relies on the for initial setup including CPU configuration, access, and basic I/O. In some or implementations, it may perform limited initialization such as CPU mode switching or temporary configuration. Due to its position early in the boot chain, the primary bootloader operates under severe constraints that limit its complexity and capabilities. It is confined to an extremely small code footprint, such as the 446 bytes available in the (MBR) before the partition table and boot signature, necessitating highly optimized code without support for high-level languages or libraries. Access to file systems is unavailable at this stage, as no drivers or abstractions for formatted s exist yet; instead, it relies on raw, sector-level disk operations using predefined block addresses. Addressing is strictly absolute, operating in without segmentation or paging, which restricts memory usage to physical locations below 1 MB and demands precise offset calculations to avoid overlaps with data structures. These limitations ensure the bootloader remains lightweight and resilient but require careful design to avoid errors that could halt the boot process irretrievably. The loading mechanism for the primary bootloader is firmware-specific but follows a standardized handoff protocol in many architectures. In x86 systems using legacy , the firmware executes 0x19 upon detecting a bootable device, which loads the first 512-byte sector (containing the primary bootloader) into memory at absolute address 0x7C00 and jumps to it for execution. To read additional sectors for the secondary stage, the bootloader invokes 0x13, specifying parameters like (CHS) or (LBA) to transfer data directly into without intermediary buffering. This interrupt-driven approach leverages the firmware's pre-initialized disk services, bypassing the need for custom drivers. Illustrative examples highlight the primary bootloader's emphasis on simplicity and efficient transition. In the Coreboot firmware, the bootblock serves as this initial stage, implemented in compact x86 assembly to initialize Cache-As-RAM for temporary stack and heap, update CPU microcode, and set up timers before decompressing and loading the romstage, which initializes DRAM, for further execution. Similarly, in embedded ARM systems, U-Boot's Secondary Program Loader (SPL) acts as the primary bootloader, performing SDRAM controller configuration and basic peripheral enables in a minimal binary, then loading the full U-Boot image while relocating itself to RAM to free ROM space and enable larger code execution. These designs prioritize rapid handover to subsequent stages, often completing in under a second on modern hardware.

Secondary Bootloader

The secondary bootloader, loaded into RAM by the primary stage, provides advanced capabilities for initializing the operating system boot process. It supports reading from complex file systems such as and , enabling access to kernel images and configuration files stored on partitioned disks. This stage typically presents a menu-based for selecting operating systems or variants, allowing users to choose boot options interactively. Additionally, it handles if required—though many implementations load compressed images directly for the to self-decompress—and passes essential parameters, including command-line arguments and (initrd) images, to the entry point. In the loading process, the secondary bootloader scans disk partitions to locate and verify boot files, potentially authenticating them in secure environments before proceeding. Once loaded, it relocates itself fully into for execution, then chains to the by transferring control to its designated entry point after preparing the environment. This handoff from the primary loader ensures a seamless transition, building on basic hardware initialization to enable higher-level operations. Compared to the primary stage's constraints, the secondary bootloader benefits from larger size limits, often exceeding several megabytes, which allows for a modular incorporating drivers for peripherals like video output to render graphical menus. It also supports chainloading other bootloaders for compatibility with diverse systems and includes mechanisms for error recovery, such as fallback boot entries that activate alternative configurations if the primary selection fails. Prominent examples include GRUB's stage 2 in legacy versions, which provides filesystem access, menu display, and kernel loading from /boot/grub, and LILO's secondary image, installed on a partition to enable multiboot selection from supported filesystems like and . These implementations emphasize configurability and reliability in user-facing boot scenarios.

Platform-Specific Implementations

x86 Personal Computers

In x86 personal computers, legacy firmware initializes the boot process through the (MBR), a 512-byte sector at the start of the storage device that holds executable bootstrap code followed by the disk's partition table. This code, limited to 446 bytes before the partition table, loads a secondary bootloader from the active partition's . The system operates exclusively in 16-bit real mode, restricting direct memory addressing to 1 MB and relying on interrupts for hardware access. The MBR scheme imposes key limitations, including a maximum partition size of 2 TB due to 32-bit and support for only four primary s without extended structures. Representative examples of BIOS-compatible bootloaders include Legacy (version 0.97), which embeds its core image in the MBR gap between the MBR and first to enable multiboot functionality across filesystems like and , and NT Loader (), the bootstrap loader for Windows NT-based systems up to and Server 2003 that chainloads from the MBR to present an OS selection menu via the Boot.ini file. The evolution to Unified Extensible Firmware Interface () began in 2002 with Intel's release of the EFI 1.10 specification, followed by the establishment of the Forum in 2005, which advanced it into the specification through versions like 2.0 (2006), 2.1 (2007) and 2.3 (2010) to enable modular , 64-bit execution, and support for disks exceeding legacy limits. replaces MBR with the (), which uses 64-bit extents for partitions up to 9.4 zettabytes and includes redundant header copies with CRC32 checksums for integrity. Bootloaders reside in the (), a FAT32-formatted volume (typically 100-260 MB) that stores portable .efi executables; this setup facilitates secure boot integration by verifying signatures against databases and supports direct loading in without real-mode constraints. Notable UEFI implementations for x86 include GRUB2 in EFI mode, which installs to the via grub-install --target=x86_64-efi and supports natively while chainloading other OS kernels, and (bootmgfw.efi), which parses the Boot Configuration Data (BCD) store in the to manage OS entries and enable features like fast startup. For backward compatibility during the transition, many UEFI firmwares incorporate a Compatibility Support Module () that emulates behavior, allowing hybrid booting of legacy MBR devices alongside native UEFI setups. Common challenges in x86 bootloader management involve firmware-level boot order configuration, accessed via keys like F2 or Delete during to prioritize devices over legacy ones, and handling dual-boot environments where tools like edit the BCD to add entries for multiple OSes without overwriting existing chains. bootloaders typically function as secondary stages, with secure boot providing cryptographic verification as outlined in dedicated mechanisms.

Mainframe Systems

In mainframe systems, particularly those from IBM's System/360 lineage and its successors under , the boot process is known as Initial Program Load (IPL), which serves as the equivalent of a bootloader by initializing hardware, loading the operating system , and preparing the environment for batch or . Introduced with the System/360 in 1964, the IPL process was designed to support reliable, high-volume data processing in enterprise environments, departing from prior practices by allowing loading from diverse media such as card readers, magnetic tapes, or direct-access storage devices (DASD). For instance, the IPL reader would fetch an initial 24-byte bootstrap record from the selected device to locate and load the , marking a shift toward unified, compatible systems for batch-oriented workloads. The IPL functionality emphasizes system control and reliability, incorporating mechanisms like the LOADPARM parameter—specified via operator console or hardware switches—to pass configuration data during loading, including pointers to I/O definitions and system parameters. This triggers initialization, where operating system components (such as those in ) are brought online, followed by interactions with the operator console for responses to initialization queries and error handling. In virtualized environments like , the IPL command simulates this process for machines, enabling isolated of operating systems or standalone utilities from virtual devices like readers or DASD volumes, while maintaining the host's high-availability posture. Standalone loaders, such as IPL text decks from card readers, allow for utility executions without full OS involvement, contrasting with modern loaders like IEAIPL00 that handle automated sequencing from cylinder 0, track 0 on DASD. Historically, the IPL evolved from the System/360's foundational design for to accommodate and clustering in subsequent architectures, including the S/390 series introduced in 1990 and the zSeries in 2000, which extended for parallel operations across multiple central processing complexes via technologies like Parallel Sysplex. These advancements prioritized fault-tolerant initialization to minimize downtime in mission-critical settings, integrating with hardware control units through the Input/Output Configuration Data Set (IOCDS) for defining paths, control units, and devices at prior to IPL. Unlike bootloaders, mainframe IPL focuses on non-interactive, operator-supervised high-availability loading without user menus, ensuring seamless integration with enterprise I/O fabrics for sustained 24/7 operations.

Specialized Bootloaders

Embedded Systems

In systems, bootloaders are tailored for resource-constrained environments such as microcontrollers, emphasizing minimal code size, rapid execution, and seamless integration with . Unlike general-purpose systems, these bootloaders typically operate without standard file systems, relying instead on direct access to like or to load images. They bridge bare-metal execution to operating systems (RTOS) or lightweight variants, initializing essential hardware components before handing off control. Prominent examples include U-Boot, a cross-platform open-source bootloader widely used for ARM-based devices to support hardware initialization and kernel loading, and RedBoot, a debug and bootstrap designed for the RTOS that facilitates application execution on various platforms. The boot process in embedded systems features adaptations optimized for low-power and limited hardware, such as direct execution from or without intermediate storage layers. Bootloaders map flash regions to execute initial code sequences, configure for peripherals, and establish basic clocking to minimize boot time in battery-operated devices. In (IoT) applications, these bootloaders incorporate support for over-the-air () updates, enabling remote reprogramming via wireless interfaces while ensuring device reliability through validation mechanisms. This approach contrasts with more complex systems by prioritizing deterministic behavior and avoiding reliance on external peripherals during early initialization. Embedded bootloaders often employ a multi-stage to address and hardware constraints, starting with a minimal first stage like the Secondary Program Loader (SPL) in U-Boot. The SPL handles critical early tasks such as clock configuration, basic controller setup, and loading the subsequent full bootloader stage into , all while operating without a (MMU) to conserve resources. This staged design allows the initial code to fit within limited on-chip , progressively enabling more complex operations like management and device tree configuration. Such constraints ensure efficient booting on systems with kilobytes of , avoiding the overhead of full-featured loaders from the outset. These bootloaders find application in diverse embedded domains, including smartphones where the Bootloader (Aboot) manages secure image loading on processors, routers running that leverage U-Boot for customizable network initialization, and automotive electronic control units (ECUs) utilizing flash bootloaders for in-field reprogramming.

Network Booting

Network booting, also known as netbooting, enables a computer to start up without relying on local storage devices by loading the operating system and initial files from a remote over a . This approach is particularly useful for diskless workstations, thin clients, and large-scale environments where centralized simplifies deployment and . The process begins with the system's , such as a option on network interface cards (NICs), detecting the absence of local boot media and initiating a network boot sequence. The primary protocol for modern network booting is the (PXE), a standardized client-server framework developed by and released in version 2.0 in December 1998, with version 2.1 following in September 1999. PXE operates over UDP/IP and extends the (BOOTP), defined in RFC 951 (1985), to allow diskless clients to discover their IP address and boot server location. In the PXE process, the client broadcasts a DHCPDISCOVER packet to obtain an via (DHCP), which also provides the IP of the (TFTP) server and the name of the boot file, typically a secondary bootloader like pxelinux.0 from the project. The client then downloads this bootloader via TFTP, which in turn loads the and (initrd) over TFTP or (NFS), enabling the full operating system to boot. For legacy Unix systems, BOOTP (without DHCP extensions) was commonly used in the 1980s and 1990s to support diskless workstations by providing basic network configuration and boot file locations. Once the secondary bootloader executes, it supports advanced configurations such as loading the directly via NFS for stateless or clustered environments. This facilitates setups, where multiple low-resource devices access a shared remote OS image, and (HPC) clusters, where s boot uniformly from a head . Network has been integral to HPC since the late , coinciding with the rise of clusters built from commodity PCs, as PXE standardized remote provisioning for scalable systems. Key implementations include iPXE, an open-source firmware that enhances PXE with features like HTTP/S support, scripting for conditional booting, and chainloading other bootloaders. iPXE evolved from gPXE (released around 2008), which itself derived from the Etherboot project, providing greater flexibility than standard PXE ROMs for complex deployments. These tools are widely used in enterprise and research settings to automate OS installation across hundreds of nodes. Network booting offers significant advantages, including the elimination of local storage costs and the ability to centrally update OS images across all clients simultaneously, which is ideal for maintaining consistency in thin client networks or HPC clusters. However, it introduces limitations such as dependency on network reliability, where high latency can prolong boot times, and vulnerability to interception in untrusted networks due to the lack of built-in encryption in core PXE protocols.

Security and Modern Developments

Secure Boot Mechanisms

Secure Boot mechanisms employ cryptographic techniques to verify the integrity and authenticity of bootloaders and subsequent components, thereby preventing the execution of unauthorized or tampered code during system startup. At the core of these mechanisms is the establishment of a , originating from the as the root of trust and extending to the operating system loader. This chain relies on digital signatures facilitated by (PKI) using certificates, where each boot stage authenticates the next by validating signatures against trusted keys stored in secure databases. Hash verification, commonly utilizing the SHA-256 algorithm, computes digests of boot images to detect any modifications, ensuring that only unaltered, signed code proceeds. A prominent implementation is UEFI Secure Boot, which integrates these concepts into the Unified Extensible Firmware Interface () environment. Introduced and enabled by default in and subsequent versions starting in 2012, it mandates the use of Microsoft-provided keys, such as the Platform Key (PK) and Key Exchange Key (KEK), while supporting third-party Certificate Authorities (CAs) for broader ecosystem compatibility. The mechanism disables the loading of unsigned drivers and bootloaders by cross-referencing executables against allowed signature databases (db) and revoking forbidden ones (dbx), thereby blocking pre-OS vectors. To address platform-specific needs, various implementations extend these core concepts. In distributions compatible with Secure Boot, the Shim bootloader acts as a signed intermediary—authenticated by keys—that subsequently verifies and chains to the native bootloader, such as , enabling secure booting without compromising open-source flexibility. Android's Verified Boot, conversely, incorporates dm-verity, a kernel-level feature that verifies the system partition's block integrity through Merkle tree-based hashes, ensuring the chain of trust from bootloader to OS images while incorporating rollback protection against persistent exploits. Additionally, measured boot leverages Trusted Platform Modules (TPMs) to hash and store boot measurements in Platform Configuration Registers (PCRs), facilitating remote attestation where a verifier can confirm the entire boot process against expected values without halting execution. These mechanisms are standardized by the Trusted Computing Group (TCG), whose specifications, dating back to 2003, define protocols for secure and measured , including event logging into TPM PCRs via the EFI Platform Specification. TCG standards enhance resistance by enforcing verified execution chains that thwart rootkits and boot-time attacks, as unauthorized alterations fail . However, they introduce drawbacks, such as update restrictions that necessitate secure and signed revisions to avoid breaking the trust chain, potentially complicating custom or legacy software deployments.

Bootloader Vulnerabilities and Mitigations

Bootloaders are susceptible to various vulnerabilities that can compromise the of the , allowing attackers to gain persistent access at a low level. Bootkits, a subset of , target the (MBR) or bootloader components to embed malicious code that executes before the operating system loads, evading traditional antivirus detection. A notable historical example is LoJax, the first UEFI discovered in the wild in 2018, attributed to the Russian APT group Sednit (also known as or APT28); it infects the SPI containing the , enabling persistence even after OS reinstallation by modifying components to load early in the . compromises represent another risk, where vulnerabilities introduced during bootloader development or distribution—such as tampered images—can propagate to end-user systems, as seen in broader incidents affecting . Evil maid attacks exploit physical access to tamper with bootloaders, such as by rewriting boot sectors or disabling security features to install persistent malware. In one variant, an attacker with brief physical access to a device can modify the EFI System Partition (ESP) to deploy bootkits like ESPecter, which loads malicious drivers during the UEFI boot phase without altering the firmware itself. Attack vectors often involve physical manipulation, such as sector rewriting on storage devices to alter the MBR or boot partition, particularly effective against legacy BIOS systems lacking cryptographic verification. For UEFI-based systems, unsigned update exploits allow attackers to bypass signature checks; for instance, vulnerabilities in signed third-party UEFI bootloaders enable arbitrary code execution by exploiting flaws in update mechanisms, rendering Secure Boot ineffective. Side-channel attacks, including timing discrepancies during hash verification in boot processes, can leak sensitive keys or validation data, though such exploits remain rare and require precise measurement of execution times. To counter these threats, full disk encryption integrated with hardware security modules provides a robust mitigation by protecting boot-related data even if the bootloader is compromised. , Microsoft's encryption solution, leverages the (TPM) to seal encryption keys to platform measurements, ensuring that tampering with the bootloader triggers a recovery key prompt or boot failure, as the TPM verifies the boot chain's integrity before releasing keys. Runtime measurements enhance this by extending TPM Platform Configuration Registers (PCRs) with hashes of bootloader and kernel components during boot, allowing remote attestation to detect alterations post-deployment; this measured boot approach records the entire chain for later verification against expected values. Bootloader locking mechanisms, such as those in or configurations, enforce verified boot states by preventing unsigned modifications and requiring explicit unlocking for updates, thereby limiting physical tampering vectors. Auditing tools like Chipsec facilitate proactive defense by providing a framework to test platform security, including checks for firmware implants, SPI flash access, and bootloader vulnerabilities across Windows, , and environments. Post-2020 developments have emphasized revocable security policies to address evolving threats. Secure Boot Advanced Targeting (SBAT), introduced as an extension to Secure Boot, uses versioned revocation lists embedded in bootloaders to block execution of known vulnerable components without full database updates; for example, a 2024 Windows security update applied SBAT policies to prevent outdated shim bootloaders in distributions from loading, enhancing revocation speed for flaws. In November 2024, researchers discovered Bootkitty, the first bootkit designed for systems, which exploits the LogoFAIL vulnerability (CVE-2023-40238) to bypass Secure Boot and deploy a rootkit targeting the . In January 2025, another Secure Boot bypass , CVE-2024-7344, was identified in the Howyar Reloader application, allowing execution of unsigned on the majority of -based systems. Additionally, in March 2025, disclosed multiple in GRUB2 using AI-assisted analysis, some enabling Secure Boot bypass and arbitrary execution during the boot process. Integration with hardware roots like Boot Guard further strengthens mitigations by verifying the initial and bootloader signatures using a fused key in the , preventing unauthorized from executing early in the boot and providing a tamper-resistant foundation against persistent . These advancements collectively reduce the by combining cryptographic enforcement with dynamic and hardware anchoring.

References

  1. [1]
    Bootloader: What is it and how does it work? - IONOS
    May 11, 2022 · A bootloader, or boot program, loads operating system data into main memory during startup, acting as a mediator between hardware and the OS.
  2. [2]
    Booting ARM Linux - The Linux Kernel documentation
    In order to boot ARM Linux, you require a boot loader, which is a small program that runs before the main kernel.
  3. [3]
    Configure and edit boot options in Windows for driver development
    Learn about boot options in Windows, including the boot loader architecture, boot configuration, and the BCDEdit editing tool.
  4. [4]
    Bootloader - an overview | ScienceDirect Topics
    A bootloader is defined as a separate program in memory that executes during system restart to determine whether to load a new application or run an existing ...
  5. [5]
    What is a Boot Loader (Boot Manager)? - TechTarget
    Jul 9, 2024 · A boot loader (boot manager) is a small program that places the operating system (OS) of a computer into memory.
  6. [6]
    https://www.techtarget.com/searchdatacenter/definition/boot-loader-boot-manager
  7. [7]
    [PDF] UG103.6: Bootloader Fundamentals - Silicon Labs
    A bootloader is a program in flash memory that initializes a device, updates firmware, and can perform integrity checks. It can be standalone or application ...
  8. [8]
    What is a Bootloader and when do you need one?
    Nov 8, 2022 · A bootloader is a small OS, or application, designed to download firmware in the embedded device (MCU's internal or external memory).
  9. [9]
    Bootloader overview | Android Open Source Project
    Oct 9, 2025 · A bootloader is a vendor-proprietary image responsible for bringing up the kernel on a device. The bootloader guards the device state.
  10. [10]
    1. The Linux/x86 Boot Protocol — The Linux Kernel documentation
    The boot image which was loaded. Again, the meaning of <file> is obviously bootloader-dependent. auto. The kernel was booted without explicit user intervention.<|separator|>
  11. [11]
    From bootloader to kernel · Linux Inside - 0xax
    After initializing and checking the hardware, the BIOS needs to find a bootable device. A boot order is stored in the BIOS configuration, controlling which ...
  12. [12]
    Master Boot Record (MBR) explained - IONOS
    Nov 22, 2022 · The master boot record is a relic from the beginnings of PC technology. It was introduced for the first time in 1983 with IBM PC DOS 2.0 and ...
  13. [13]
    How Boot Loaders Work - Lennart Benschop
    The boot sector program can only be 512 bytes in size and not all 512 bytes are even available in all cases. The last two bytes must be 0x55 and 0xAA for the ...<|separator|>
  14. [14]
    [PDF] A Comprehensive Memory Safety Analysis of Bootloaders
    Feb 24, 2025 · Due to the limited environment support, the bootloader is designed and implemented as a self-contained standalone application. Peripheral ...
  15. [15]
    Microcode Update Guidance - Intel
    Dec 6, 2020 · After loading an update from the FIT, the bootstrap processor (BSP) begins fetching and executing the BIOS firmware from the IA reset vector, ...
  16. [16]
    Windows boot issues troubleshooting - Microsoft Learn
    Apr 28, 2025 · PreBoot: The PC's firmware initiates a power-on self test (POST) and loads firmware settings. This pre-boot process ends when a valid system ...
  17. [17]
    3. Boot Manager — UEFI Specification 2.10 documentation
    The boot manager will attempt to load UEFI drivers and UEFI applications (including UEFI OS boot loaders) in an order defined by the global NVRAM variables.Missing: POST | Show results with:POST
  18. [18]
    4. EFI System Table — UEFI Specification 2.10 documentation
    EFI System Table¶. This section describes the entry point to a UEFI image and the parameters that are passed to that entry point.4.1. Uefi Image Entry Point · 4.3. Efi System Table · 4.4. Efi Boot Services TableMissing: POST bootloader
  19. [19]
    1. Introduction — UEFI Specification 2.10 documentation
    The intent of this specification is to define a way for the OS and platform firmware to communicate only information necessary to support the OS boot process.Missing: POST bootloader
  20. [20]
    coreboot architecture
    Stages . coreboot consists of multiple stages that are compiled as separate binaries and are inserted into the CBFS with custom compression. The bootblock ...
  21. [21]
    Boot Flow — Slim Bootloader 1.0 documentation
    Stage 1A. Pre-memory initialization ; Stage 1B. Initialize main memory ; Stage 2. Post memory initialization: initialize CPU, I/O controllers, devices etc.
  22. [22]
    Generic xPL framework — Das U-Boot unknown version documentation
    ### Summary of U-Boot SPL
  23. [23]
    Make the most of large drives with GPT and Linux - IBM Developer
    Jul 3, 2012 · The MBR itself resides entirely on the first sector (512 bytes) of a hard disk. The first 440 bytes of the MBR are devoted to code: the boot ...
  24. [24]
    Chapter 1. Bootstrapping and Kernel Initialization
    As mentioned previously, we're calling the BIOS INT 0x19 to load the MBR (boot0) into memory at address 0x7c00 . The source file for boot0 can be found in ...
  25. [25]
    GNU GRUB Manual 2.12
    GNU GRUB is a very powerful boot loader, which can load a wide variety of free operating systems, as well as proprietary operating systems with chain-loading.<|control11|><|separator|>
  26. [26]
    9.2. GRUB | Installation Guide | Red Hat Enterprise Linux | 5
    The Stage 2 or secondary boot loader is read into memory. The secondary boot loader displays the GRUB menu and command environment. This interface allows ...
  27. [27]
    Kernel decompression | linux-insides - GitBook
    Oct 19, 2025 · The kernel itself is already loaded by the bootloader but it is in a compressed form. Before we can reach the real kernel entry point, this ...
  28. [28]
    Booting fallback systems - GNU GRUB Manual 0.97
    GRUB supports a fallback mechanism of booting one or more other entries if a default boot entry fails. You can specify multiple fallback entries if you wish.
  29. [29]
    Linux System Administration: Using LILO, The Linux Loader
    Nov 1, 1995 · Linux provides LILO, the Linux Loader, which can function as either a master boot program or a secondary boot program. lilo is installed ...
  30. [30]
    [PDF] Unified Extensible Firmware Interface (UEFI) Specification
    ... boot a UEFI-compliant OS. The UEFI Driver Model is designed to be generic and can be adapted to any type of bus or device. The UEFI Spec ...Missing: bootloader | Show results with:bootloader<|control11|><|separator|>
  31. [31]
    Windows and GPT FAQ
    ### Summary: MBR Limitations and GPT Advantages for x86 PCs
  32. [32]
    GNU GRUB Manual 0.97
    This is the documentation of GNU GRUB, the GRand Unified Bootloader, a flexible and powerful boot loader program for pcs. This edition documents version 0.97.
  33. [33]
    troubleshoot "NTLDR Is Missing" error - Windows - Microsoft Learn
    Jan 15, 2025 · The "NTLDR is missing" error may occur due to outdated BIOS or missing/damaged boot files. Verify BIOS and use methods like a boot disk or ...
  34. [34]
    Specifications | Unified Extensible Firmware Interface Forum
    ### Summary of UEFI Development History and Transition from BIOS (2005-2010)
  35. [35]
    Unified Extensible Firmware Interface - Intel
    Sep 6, 2019 · Intel's original version of this specification was publicly named EFI, ending with the EFI 1.10 version. In 2005, The Unified EFI Forum was ...Missing: history timeline
  36. [36]
    UEFI/GPT-based hard drive partitions - Microsoft Learn
    Feb 10, 2023 · On GPT drives, this is known as the EFI System Partition, or the ESP. This partition is usually stored on the primary hard drive. The device ...
  37. [37]
    How to manage the Windows Boot Manager revocations for Secure ...
    Install the updated certificate definitions to the DB. This step will add the “Windows UEFI CA 2023” certificate to the UEFI “Secure Boot Signature Database” ( ...
  38. [38]
    Boot to UEFI Mode or Legacy BIOS mode - Microsoft Learn
    Dec 15, 2021 · To boot to UEFI or BIOS: · Boot the PC, and press the manufacturer's key to open the menus. Common keys used: Esc, Delete, F1, F2, F10, F11, or ...Missing: x86 2005-2010
  39. [39]
    Dual-Boot Guides - NeoSmart Technologies
    EasyBCD supports dual-booting into legacy Microsoft OS (DOS, XP, 2000, 2003), newer Windows (Vista, 7, 8, 10), Linux (Ubuntu, Fedora), Mac OS X, and BSD.
  40. [40]
    IPL of Older IBM Systems - DOS/360 Installation - Google Sites
    The IBM System/360 departed from past practice and allowed for IPL from any card reader, tape, or disk. IPL read 24 bytes from the selected device.
  41. [41]
    The IBM System/360
    Launched on April 7, 1964, the System/360 was so named because it was meant to address all possible types of users with one unified software-compatible ...
  42. [42]
    Specifying LOAD information - IBM
    LOADxx allows you to specify I/O configuration data and information about the IODF data set, the nucleus, the master catalog, and the IEASYMxx and IEASYSxx ...
  43. [43]
    System IPL: Sequence and key controls - IBM
    The initialization process begins when the system programmer or operator selects the LOAD function at the Hardware Management Console (HMC).Missing: 360 | Show results with:360
  44. [44]
    IPL - IBM
    Use the IPL command to simulate an initial program load (IPL) function for your virtual machine. The IPL command can specify four methods to IPL a virtual ...
  45. [45]
    [PDF] PRS3699 IPL Logic Flow V2 - IBM
    Hardware IPL. Hardware IPL Overview. ▫Process is defined by the z/Architecture. ▫Controlled by hardware. ▫ Cyl 0, Trk 0, R1, R2, IEAIPL00. ▫A single CPU is ...
  46. [46]
    [PDF] The Evolution of IBM Mainframes and VM
    Sep 19, 2005 · IBM mainframes have evolved for over 50 years. This presentation will cover the history of IBM mainframes from the IBM 701 through.
  47. [47]
    Mainframe hardware: System control and partitioning - IBM
    Partitioning control specifications are partly contained in the IOCDS and are partly contained in a system profile. The IOCDS and profile both reside in the ...
  48. [48]
    Mainframe hardware: I/O connectivity - IBM
    The I/O control layer uses a control file known as an IOCDS (I/O Control Data Set) that translates physical I/O addresses (composed of CHPID numbers, switch ...
  49. [49]
    RedBoot - Sourceware
    RedBoot allows download and execution of embedded applications via serial or ethernet, including embedded Linux and eCos applications. It can be used for both ...
  50. [50]
    Bootloader And Stages of Booting Process Explained!
    Jul 3, 2019 · An embedded bootloader is a piece of software that takes a system from a power-up state to a usable state.Stage 2: Bootloader Mode Or... · Uses Of Bootloader Mode In... · Bootloader Security
  51. [51]
    Over-The-Air Bootloaders | Microchip Technology
    Oct 3, 2024 · Discover the benefits and applications of OTA bootloaders, enabling seamless wireless firmware updates for embedded systems and IoT devices.
  52. [52]
    Over-the-Air (OTA) Updates in Embedded Microcontroller Applications
    In this article, we will describe several different software designs for OTA updates and discuss their trade-offs.
  53. [53]
    Generic SPL framework - The U-Boot Documentation
    SPL. Secondary program loader. Sets up SDRAM and loads U-Boot proper. It may also load other firmware components. U-Boot.Missing: embedded | Show results with:embedded
  54. [54]
    Device state | Android Open Source Project
    Sep 24, 2024 · The device state indicates how freely software can be flashed to a device and whether verification is enforced. Device states are LOCKED and UNLOCKED.
  55. [55]
    [OpenWrt Wiki] The Bootloader
    Oct 9, 2022 · The bootloader is a piece of software that is executed every time the hardware device is powered up. It is executable machine code and thus ARCH-specific.Das U-Boot · Breed · CFE · Adam2
  56. [56]
    Flash Bootloader - Vector
    The Vector Flash Bootloader is a universal solution for the reprogramming of ECUs during development, while in production or while in service.Flash Bootloader - Ecu... · Advantages · Supported Hardware And...
  57. [57]
    Bootloader design for microcontrollers in embedded systems - EDN
    Sep 3, 2013 · A boot-loader is an application whose primary purpose is to allow a systems software to be updated without the use of specialized hardware such as a JTAG ...
  58. [58]
    [PDF] UEFI PXE Boot Performance Analysis - Intel
    This document analyzes firmware and OS elements impacting UEFI network boot performance, focusing on the PXE client and how network topology affects boot time.
  59. [59]
    [PDF] Preboot Execution Environment (PXE) Specification
    Sep 20, 1999 · System Management BIOS Reference Specification. [SM BIOS]. Version 2.2, March 16, 1998 ftp://download.intel.com/ial/wfm/smbios.pdf http://www ...
  60. [60]
    RFC 951 - Bootstrap Protocol - IETF Datatracker
    This RFC describes an IP/UDP bootstrap protocol (BOOTP) which allows a diskless client machine to discover its own IP address, the address of a server host, ...
  61. [61]
    The History of Cluster HPC - ADMIN Magazine
    The history of cluster HPC is rather interesting. In the early days, the late 1990s, HPC clusters, or “Beowulfs” as they were called, were often cobbled ...
  62. [62]
    Building a Linux cluster using PXE, DHCP, TFTP and NFS
    A Linux cluster uses a head node with two network cards, worker nodes booting via PXE, and a shared read-only NFS filesystem. Worker nodes boot over a small  ...
  63. [63]
    iPXE - open source boot firmware [start]
    Jan 26, 2021 · iPXE is the leading open source network boot firmware. It provides a full PXE implementation enhanced with additional features.Documentation · Download · Chainloading iPXE · Burning iPXE into ROM
  64. [64]
    What Is PXE Boot and How Does It Work? - Heimdal Security
    Oct 3, 2025 · Advantages of Using the PXE Boot Process · Fewer technical installers; · Less time spent per server; · Fewer errors due to automation; · Centralized ...
  65. [65]
    What is Preboot Execution Environment (PXE)? - TechTarget
    Nov 23, 2021 · Some of the crucial advantages of PXE booting include the following: The client does not require an operating system or storage device.
  66. [66]
    What are the biggest security concerns on PXE?
    Aug 8, 2014 · The top security concern is that the only protection of traditional PXE booting is physical security. There is no encryption or authentication ...
  67. [67]
    32. Secure Boot and Driver Signing — UEFI Specification 2.9A ...
    This identifies a signature containing a RSA-2048 signature of a SHA-256 hash. The SignatureHeader size shall always be 0. The SignatureSize shall always be ...Missing: PKI | Show results with:PKI
  68. [68]
    Windows Secure Boot Key Creation and Management Guidance
    Sep 5, 2025 · This document helps guide OEMs and ODMs in creation and management of the Secure Boot keys and certificates in a manufacturing environment.
  69. [69]
    UEFI Secure Boot - Ubuntu documentation
    The Linux community relies on this model for Secure Boot compatibility. ... shim works as a pre-bootloader and has been signed by Microsoft. Firmware ...
  70. [70]
    Verified Boot | Android Open Source Project
    Aug 26, 2024 · Android 4.4 added support for Verified Boot and the dm-verity kernel feature. This combination of verifying features served as Verified Boot 1.Implement dm-verity · Android Verified Boot · Documentation · Boot flow
  71. [71]
    Measured boot and host attestation - Azure Security - Microsoft Learn
    Sep 10, 2024 · This article describes how Microsoft ensures integrity and security of hosts through measured boot and host attestation.Measured boot · Host Attestation Service
  72. [72]
    TCG EFI Platform Specification | Trusted Computing Group
    This specification contains the requirements for measuring boot events into TPM PCRs and adding boot event entries into the Event Log.
  73. [73]
    [PDF] TCG Guidance for Secure Update of Software and Firmware on ...
    Feb 10, 2020 · Today's attackers increasingly aim to replace firmware and software on devices with their own malicious code to establish a permanent foothold ...
  74. [74]
    Rootkits: Definition, Types, Detection, and Protection - SentinelOne
    Aug 11, 2025 · Bootkits: A bootkit is a kind of rootkit that infects the MBR or bootloader. It embeds itself deep into the boot process of the system ...Missing: evil maid supply chain
  75. [75]
    The lowdown on LoJax: Researchers detect a UEFI rootkit in the wild
    Sep 27, 2018 · The Russian APT group Sednit (aka Fancy Bear and APT28) is strongly suspected to be the culprit behind a new rootkit malware program that ...
  76. [76]
    The Top Firmware and Hardware Attack Vectors
    Apr 16, 2025 · The Top Firmware and Hardware Attack Vectors · Widespread Attacks Against VPN Devices and Firmware · New Firmware · Newly Discovered UEFI Implants ...
  77. [77]
    UEFI threats moving to the ESP: Introducing ESPecter bootkit
    Oct 5, 2021 · The attacker has physical access to the device (historically known as an “evil maid” attack) and manually disables Secure Boot in the BIOS setup ...Missing: supply | Show results with:supply
  78. [78]
    Master Boot Record - an overview | ScienceDirect Topics
    The Master Boot Record (MBR) is defined as the traditional partition style that contains a partition table describing the location of partitions on a disk.
  79. [79]
    Signed third party UEFI bootloaders are vulnerable to Secure Boot ...
    Aug 11, 2022 · A security feature bypass vulnerability exists in signed 3rd party UEFI bootloaders that allows bypass of the UEFI Secure Boot feature.
  80. [80]
    SoK: Security Below the OS – A Security Analysis of UEFI - ar5iv
    By comprehensively examining these parameters, this attack threat model aims to shed light on the intricacies of UEFI attacks and provide valuable insights to ...
  81. [81]
    [PDF] Trusted Platform Module (TPM) Use Cases - DoD
    Nov 6, 2024 · TPMs are widely used to harden Full Disk Encryption (FDE) implementations that encrypt data-at-rest. DISA STIGs require data-at-rest ...<|separator|>
  82. [82]
    10.7. Measured Boot Design - Trusted Firmware-A Documentation
    Measured Boot is the process of computing and securely recording hashes of code and critical data at each stage in the boot chain before the code/data is used.
  83. [83]
    Lock and unlock the bootloader | Android Open Source Project
    Oct 9, 2025 · To lock the bootloader and reset the device, run the fastboot flashing lock command on the device. Devices intended for retail should be shipped ...
  84. [84]
    GitHub - chipsec/chipsec: Platform Security Assessment Framework
    ### Overview of Chipsec: Purpose and Features
  85. [85]
    On Secure Boot, TPMs, SBAT, and downgrades -- Why Microsoft ...
    Jan 17, 2025 · I'll first lay some groundwork on how Secure Boot and the TPM work, discuss PCRs and which one you might use for BitLocker, and explore the ecosystem's future.