Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Introduction to UEFI HTTP(s) Boot with QEMU/OVMF

blog.yadutaf.fr

Post reply on HN
Print view View original

31–35 of 35 posts

Re: Introduction to UEFI HTTP(s) Boot with QEMU/OVMF

#31

Post by bigfatkitten »

naturalmovement wrote: post #24
rwmj wrote: post #20

Earlier quoted context omitted.

In theory the client could validate a specific server with a pinned certificate, although TLS implementations can make this difficult to do in practice. TLS also lets you use client certificates to authenticate the client to the server, which could be a win in some situations (although also a PITA to set up).

I can guarantee you with nearly 100% certainty that UEFI TLS clients are bound to be buggy garbage broken in not-insignificant ways.

The IP stack and HTTP clients are problematic enough without adding the enormous complexity of a TLS implementation on top.

Re: Introduction to UEFI HTTP(s) Boot with QEMU/OVMF

#32

Post by RulerOf »

naikrovek wrote: post #27
my-boot wrote: post #15

Earlier quoted context omitted.

Unfortunately, Apple seems to be alone in having a good implementation. Using the old PXE, you expect to see some dos-like screens and slow loading but with HTTP the experience is not much better. Any decently sized bootloader is downloaded at a snails-pace and the user is presented with a very technical screen. Fine for rescue-boot like purposes but not fine when your daily driver is expected to be booted from netwo…

> slow loading Not necessarily. When I worked at Yahoo, in Australia (what a glorious time that was) 25 years ago, I built servers in the datacenter using PXE. It was anything but slow. Unbox a server, plug it into the PXE network, boot it. It boots to a miniscule FreeBSD distribution and you use a common user/pass to log in. Then, you type clone -h and it mounted an NFS share and installed packages and config files…

> Why can’t I set up Windows or MacOS like that? I know the answer I just find the answer annoying.

I wish I still cared about this. I had intended to build an iPXE boot menu via a small web service that would act as a windows install XML template editor/selector, but I never got around to doing it after learning enough web dev to pull it off.

I built a few similar things that worked inside of WinPE, but the slowness of waiting for it to boot was always what drove me to do as much config as possible in the PXE boot menu—you can get into that in seconds versus minutes for the PE.

I used to install Windows a lot, and found a lot of tech around it to be a little too opinionated. SMS/WDS were just too legacy-leaning and Microsoft Enterprise-flavored. FOG was a little too heavy-handed (though very good). Glazier excited me but I never actually used it to determine if it has the flexibility I wanted...

But I digress. OS installs should be a lot easier and faster to accept your configuration preferences and get to work when the goal is "erase this machine and reinstall" than they are even today.

Re: Introduction to UEFI HTTP(s) Boot with QEMU/OVMF

#33

Post by naturalmovement »

bigfatkitten wrote: post #31
naturalmovement wrote: post #24

Earlier quoted context omitted.

I can guarantee you with nearly 100% certainty that UEFI TLS clients are bound to be buggy garbage broken in not-insignificant ways.

The IP stack and HTTP clients are problematic enough without adding the enormous complexity of a TLS implementation on top.

They have a hard enough time managing the relatively few certificates for secure boot.

You want me to believe all the various BIOS manufacturers are going to competently manage a WebPKI root certificate program?

Re: Introduction to UEFI HTTP(s) Boot with QEMU/OVMF

#34

Post by quesomaster9000 »

noodlesUK wrote: post #3

To what extent is this possible for actual metal hardware? I'm sure lots of us are running PXE/TFTP systems and HTTP would be a heck of a lot simpler.

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.

[1]: https://wavebend.org/blog/2026-06-13-stage0-http-netboot/

Re: Introduction to UEFI HTTP(s) Boot with QEMU/OVMF

#35

Post by marysol5 »

RulerOf wrote: post #32
naikrovek wrote: post #27

Earlier quoted context omitted.

> slow loading Not necessarily. When I worked at Yahoo, in Australia (what a glorious time that was) 25 years ago, I built servers in the datacenter using PXE. It was anything but slow. Unbox a server, plug it into the PXE network, boot it. It boots to a miniscule FreeBSD distribution and you use a common user/pass to log in. Then, you type clone -h and it mounted an NFS share and installed packages and config files…

> Why can’t I set up Windows or MacOS like that? I know the answer I just find the answer annoying. I wish I still cared about this. I had intended to build an iPXE boot menu via a small web service that would act as a windows install XML template editor/selector, but I never got around to doing it after learning enough web dev to pull it off. I built a few similar things that worked inside of WinPE, but the slowness…

Built out a (i)PXE build system for Windows at an /old job/

It would chain load the iPXE binary from the network, then call out to a HTTP end-point with "?mac={macaddress}" so we could identify it. Then it would auto-pull from git, or generate (and push into git) a config, which would load the WinPE image over the network, and launch a powershell script. All of which would talk back to the HTTP endpoint throughout.

Because we tracked it all with a Slackbot on every execution.

Fun hack, certutil.exe has the ability to do HTTP/S requests, so we would leverage that to "live off the land", even though we could integrate any binary into the image outselves.

Post reply on HN