UEFI PXE vs Legacy BIOS Network Boot Differences

Network booting allows a computer to load an operating system or deployment environment directly from a server without using local storage. While both Preboot Execution Environment (PXE) under legacy BIOS and modern UEFI PXE achieve the same end goal, they function under fundamentally different firmware architectures. UEFI PXE introduces significant advancements over legacy BIOS network booting, including 64-bit processor execution, native security features like Secure Boot, enhanced networking protocols beyond TFTP, and support for modern partition schemes.

Architecture and Memory Addressing

Legacy BIOS operates in a 16-bit processor mode known as real mode, which imposes a strict 1 MB memory limit. Because of this, legacy PXE uses small, primitive network card drivers loaded into limited Option ROM space. This severely constrains the size, complexity, and performance of the Network Bootstrap Program (NBP).

In contrast, UEFI PXE executes in 32-bit or 64-bit mode from the moment initialization begins. This allows network drivers and pre-boot programs to access all installed system memory directly. As a result, UEFI can load complex environments, higher-resolution interfaces, and modern drivers before handing control over to the operating system.

Network Protocols and Transfer Methods

Legacy PXE relies strictly on the Trivial File Transfer Protocol (TFTP) over IPv4 via UDP. TFTP is unencrypted, lacks flow control, and transfers data in small, sequential blocks, making large operating system images slow and prone to timeout errors over high-latency networks.

UEFI PXE expands network capabilities substantially:

  • Protocol Diversity: UEFI supports modern protocols, including full native IPv6 stacks alongside IPv4.
  • HTTP/HTTPS Booting: Modern UEFI specifications support downloading boot images via HTTP and HTTPS rather than TFTP. This drastically reduces transfer times by utilizing standard TCP windowing and enables encrypted, authenticated transfers over WAN environments.
  • DNS and Routing Support: UEFI firmware can resolve hostnames natively and handle routing without requiring the rigid, broadcast-dependent network topologies legacy PXE demands.

Security and Secure Boot

A critical limitation of legacy BIOS is its inability to verify the authenticity of code executed during the boot stage. Anyone on the local network capable of spoofing a DHCP response or altering a TFTP server can serve malicious bootloaders to a client machine.

UEFI PXE resolves this vulnerability by integrating with UEFI Secure Boot. When enabled, the firmware checks the cryptographic signature of the .efi bootloader against known, trusted keys embedded in the platform firmware (such as Microsoft's Third-Party UEFI CA). If the boot file has been tampered with or lacks a valid signature, the system refuses to boot, stopping rootkits and bootkits at the firmware level.

DHCP Architecture and Boot Files

Because legacy BIOS and UEFI require different executable formats, DHCP servers must be configured to differentiate between the two client types:

  • File Types: Legacy PXE requires flat binary files or specialized bootloaders (e.g., pxelinux.0, wdsnbp.com). UEFI requires standard Portable Executable (PE32+) binaries with the .efi extension (e.g., bootx64.efi, wdsmgfw.efi).
  • Client Identification (Option 93 / 60): UEFI devices inform the DHCP server of their architecture during the initial DHCP Discover request using DHCP Option 93 (Client System Architecture Type). A legacy client reports as 0000, while an x86-64 UEFI client reports as 0007 or 0009. DHCP policies utilize these flags to serve the correct boot file via Option 67.

Disk Formatting and Partitioning

Legacy BIOS booting binds the operating system to the Master Boot Record (MBR) partitioning scheme, which restricts drive sizes to a maximum of 2 terabytes and limits systems to four primary partitions.

UEFI PXE pairs natively with the GUID Partition Table (GPT) scheme. Booting over UEFI PXE ensures that the operating system installer deploys to GPT-formatted drives, removing the 2-terabyte capacity limit and accommodating up to 128 partitions natively in standard configurations.