Introduction to UEFI HTTP(S) boot with Qemu/OVMF | Yet another enthusiast blog!Introduction to UEFI HTTP(S) boot with Qemu/OVMF<br>Jun 12, 2026<br>#qemu<br>#ovmf<br>#boot

The historic go-to solution for network booting is PXE. PXE is based on DHCP and<br>TFTP. It is tricky to correctly configure, even trickier to make it highly available and<br>good luck with the security with this clear-text unsigned protocol.<br>The modern web has long standardized on HTTPS with TLS certificates for server authentication,<br>integrity and confidentiality. Moreover, highly available setups are a solved problem when<br>it comes to HTTPS. Even better, the encryption layer makes it practical to boot over the<br>Internet without immediately facing the threat of a man-in-the-middle attack that would be<br>trivial with TFTP (remember, the leading t stands for &ldquo;trivial&rdquo;, not &ldquo;secure&rdquo;).<br>The good news is, most modern UEFI-based system support booting over HTTP(S).<br>In this post, we&rsquo;ll boot the snponly variant of netboot.xyz directly<br>from the official website. Be prepared for some fun with HTTPS.<br>All these tests were performed on Ubuntu 26.04 with the provided 1:10.2.1+ds-1ubuntu3 Qemu<br>and 2025.11-3ubuntu7 OVMF packages, unless otherwise stated. Note that, for reasons that will<br>become clear later in this post, older versions might actually work better 🙃.<br>Starting with the simple case: HTTP boot discovered over DHCP<br>(Righteously) Suspecting that the HTTPS variant would be a tough beast to beat, I started<br>this journey with a first test that side steps the certificate trust and other quirks at the<br>beginning.<br>The URL for the boot firmware is: http://boot.netboot.xyz/ipxe/netboot.xyz-snponly.efi.<br>The aim here is to demonstrate a minimal setup to make it easier to integrate it in your own<br>environment. We&rsquo;ll use a non-root Qemu machine with userland-based SLIRP networking and no<br>additional devices like storage for instance. The whole system will run in-memory.<br>Let&rsquo;s start with a first iteration based on:<br>The OVMF firmware, without secure boot to keep things simple<br>A network card that will emulate a DHCP server and point the UEFI to the HTTP boot target<br>Output on the console<br>1qemu-system-x86_64 \<br>2 -drive if=pflash,format=raw,readonly=on,file=/usr/share/OVMF/OVMF_CODE_4M.fd \<br>3 -nic user,bootfile=http://boot.netboot.xyz/ipxe/netboot.xyz-snponly.efi \<br>4 -nographic

This is promising, but it fails to boot over the network:<br>1BdsDxe: No bootable option or device was found.<br>2BdsDxe: Press any key to enter the Boot Manager Menu.

This is because the network stack in the OVMF requires a random number generator device to<br>work. When you think about it, this is almost obvious. Pretty much each layer of the network<br>stack requires randomness, from Ethernet collision avoidance to TLS through DHCP itself.<br>This can be enabled very easily by adding the following flag to the Qemu command line:<br>1-device virtio-rng-pci

Any other configuration change that would provide a random number generator would work equally<br>well. For example, one could enable KVM and use -cpu host which would grant access to the CPU&rsquo;s<br>random number generation instructions.<br>While somewhat obvious, this is pretty hard to figure out without help because of the lack of<br>error logs. In this case, I was helped by asking the free version of Claude.<br>I was wondering how one could figure this out by induction/deduction rather than brute-forcing<br>it with a (very helpful) LLM. It turns out the dependency is declared in the [Depex] section<br>of NetworkPkg/Library/DxeNetLib/DxeNetLib.inf:<br>1[Depex]<br>2 gEfiRngProtocolGuid

Under the hood, this pushes the GUID of the EFI random number generation protocol on the<br>dependency stack so that any EFI package linking against the DxeNetLib will implicitly require<br>it when the dispatcher evaluates the dependencies at runtime.<br>For future reference (to myself), one could work out the dependency at runtime from the<br>debug logs by enabling the &ldquo;DEBUG_DISPATCH&rdquo; flag of gEfiMdePkgTokenSpaceGuid.PcdDebugPrintErrorLevel<br>in OvmfPkg/OvmfPkgX64.dsc. Be prepared for a world of GUID based debugging!<br>(If you are frustrated by the brute-force approach and would rather see a log-based approach,<br>stay tuned for the HTTPS part.)<br>With this in place, tadaa!<br>1>>Start PXE over IPv4.<br>2 Station IP address is 10.0.2.15<br>4 Server IP address is 10.0.2.2<br>5 NBP filename is http://boot.netboot.xyz/ipxe/netboot.xyz-snponly.efi<br>6 NBP filesize is 0 Bytes<br>7 PXE-E23: Client received TFTP error from server.<br>8BdsDxe: failed to load Boot0002 "UEFI PXEv4 (MAC:525400123456)" from PciRoot(0x0)/Pci(0x3,0x0)/MAC(525400123456,0x1)/IPv4(0.0.0.0,0x0,DHCP,0.0.0.0,0.0.0.0,0.0.0.0): Not Found<br>10>>Start PXE over IPv6.<br>11 PXE-E16: No valid offer received.<br>12BdsDxe: failed to load Boot0003 "UEFI PXEv6 (MAC:525400123456)" from...