Having http as an alternative to tftp is a nice win. The range of things that can run an http server is much bigger than tftp
>Additionally, adding the TLS layer brings back the missing integrity and confidentiality guarantees and thus paves the way to move critical boot components out of the trusted network, possibly even to a remote location/Cloud.
Doesn't secure boot already provide this or am I misunderstanding something? I suppose secure boot only provides integrity but not confidentiality although I'm not sure how much confidentiality matters given we're just talking about the kernel here
Yes, you can do this on real metal, EFI is EFI and as such you can make it do essentially whatever you want. For example recently I had to make a stage0[1] HTTP EFI bootloader, it pulls the URL and hash or pubkey from the cloud metadata service, downloads the EFI binary and chainloads it after verification.
On metal you would simply embed the URL and pubkey into the EFI loader binary (or a file on disk), put it into your ESP partition and reboot the machine. Typically the certificate DB of the machine would be reset with a single certificate that signed stage0 then switched into 'Deployed mode' so no new certificates can be added.
This separates the 'provision machine' phase from the 'machine boots and runs your latest release' phase. Although at this point we're booting UKIs so a Linux kernel + uefi stub + initramfs all in a single file.
BTW Apple has been doing HTTP boot for like two decades at this point. How do you think Internet Recovery works? It leverages a dusty old Apple netbooting spec.
The worst thing about UEFI HTTP boot is the utter lack of information to debug anything that's gone wrong. Whether that's the DHCP filename option is some wrong format for whatever stupid mode the UEFI is in, or there's some dhcp relay issue. It literally tells you almost nothing besides "can't get NBP file size".
The error messages seem to be written by people on a happy path who don't know how utterly broken almost everything about networking and DHCP even is.
And this is all IPv4! The IPv6 stuff is even more cryptic with different DHCP options and dealing with RAs and managed-flag, other-flag, etc.
It's infuriating. And I work on a team that writes code to generate all these things for automating bare metal for a living.
6 comments
[ 5.8 ms ] story [ 26.3 ms ] thread>Additionally, adding the TLS layer brings back the missing integrity and confidentiality guarantees and thus paves the way to move critical boot components out of the trusted network, possibly even to a remote location/Cloud.
Doesn't secure boot already provide this or am I misunderstanding something? I suppose secure boot only provides integrity but not confidentiality although I'm not sure how much confidentiality matters given we're just talking about the kernel here
On metal you would simply embed the URL and pubkey into the EFI loader binary (or a file on disk), put it into your ESP partition and reboot the machine. Typically the certificate DB of the machine would be reset with a single certificate that signed stage0 then switched into 'Deployed mode' so no new certificates can be added.
This separates the 'provision machine' phase from the 'machine boots and runs your latest release' phase. Although at this point we're booting UKIs so a Linux kernel + uefi stub + initramfs all in a single file.
[1]: https://wavebend.org/blog/2026-06-13-stage0-http-netboot/
The error messages seem to be written by people on a happy path who don't know how utterly broken almost everything about networking and DHCP even is.
And this is all IPv4! The IPv6 stuff is even more cryptic with different DHCP options and dealing with RAs and managed-flag, other-flag, etc.
It's infuriating. And I work on a team that writes code to generate all these things for automating bare metal for a living.