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

21–30 of 35 posts

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

#21

Post by pdmccormick »

pzmarzly wrote: post #14
nijave wrote: post #2

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 s…

> The range of things that can run an http server is much bigger than tftp Don't go too crazy though, these UEFI HTTP clients are not well behaved. For example, last time I checked, EDK required the URL to end with ".efi", instead of checking Content-Type header.

Thank you for sharing this tidbit. It looks like this may have been fixed? https://github.com/tianocore/edk2/blob/master/NetworkPkg/Htt...

I have an HTTP netboot flow that worked on older AMI Aptio firmwares, but fails on anything newer to even fetch the bootfile after a successful DHCP cycle, so I heartily agree with your sentiment that these are not necessarily well adjusted clients!

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

#22

Post by andrewjf »

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.

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

#23

Post by wmf »

andrewjf wrote: post #22

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…

It's probably a good idea to follow the path of this article and get everything working in a VM first where booting is faster and it's easier to sniff packets. Once you have vanilla OVMF working you can try booting real servers.

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

#24

Post by naturalmovement »

rwmj wrote: post #20
naturalmovement wrote: post #12

Earlier quoted context omitted.

> > adding the TLS layer brings back the missing integrity A foolish interpretation of what TLS does and I see this every day. Integrity of the bits and bytes in transit is unimportant here. Validation of the signed software after you have received it is everything. TLS integrity is at best redundant and at worst — the interpretation made here — leaves you vulnerable and with a false sense of security. Anyone who has…

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.

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

#25

Post by naturalmovement »

eggnet wrote: post #17
naturalmovement wrote: post #12

Earlier quoted context omitted.

> > adding the TLS layer brings back the missing integrity A foolish interpretation of what TLS does and I see this every day. Integrity of the bits and bytes in transit is unimportant here. Validation of the signed software after you have received it is everything. TLS integrity is at best redundant and at worst — the interpretation made here — leaves you vulnerable and with a false sense of security. Anyone who has…

TLS also allows for the contents of a boot image to be hidden from others.

Ok, but so what?

You guys are out here protecting against ghosts but at the same time making the really important stuff 10x harder and more vulnerable to bugs.

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

#26

Post by xxpor »

mschuster91 wrote: post #18
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…

> Unfortunately, Apple seems to be alone in having a good implementation. Well, Apple is in full control over their entire stack, down to the firmware on the embedded parts. In the non-Apple world, no way, simply due to the sheer insane amount of different ethernet and wireless chipsets, with many of them shipping binary blobs. The mediatek blobs alone expand to 64MB [1], Intel clocks in a further 24 MB [2], and then…

I'd guess that the mediatek blobs are exactly 64k, and mostly 0s?

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

#27

Post by naikrovek »

my-boot wrote: post #15
naturalmovement wrote: post #11

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.

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 for that hostname. In three minutes or so your server shut down and you racked it up, plugged it into the production network and it started accepting work, or it notified the engineers in the US that it was ready for use and they’d add it to a pool, then it would start handling work.

It was extremely slick.

The build network was secure because you could only access it in secure areas which had the build network and a build server deployed to it. So security was not a problem.

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

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

#28

Post by [deleted] »

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…

[deleted]

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

#29

Post by nijave »

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.

From the article, it's using OpenSSL in EDK II

In fact, a whole section of the article is dedicated to talking about how they got tripped up by OpenSSL security level 3 rejecting 2048 bit RSA key

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

#30

Post by nijave »

robertlagrant wrote: post #13
naturalmovement wrote: post #10

Earlier quoted context omitted.

> Secure boot is designed to verify software signatures aka integrity. HTTPS is a useless gesture here, adding complexity to critical software that needs to be as simple and auditable as possible. Confidentiality is essentially unimportant to anyone but the most autistic of by-the-book nerds. It buys you nothing in a practical sense. Most netbooting happens over closed networks anyway.

I agree that integrity can be done by secure boot, but HTTPS does mean that someone can't intercept your request and serve you valid, signed, older software that has a known security flaw in it.

An LLM pointed this out to me as well which I think is a fair point.

However, in practice it doesn't matter for any machine that has persistence since it only needs to netboot once to transfer an image to local storage. Besides that, you can also invert and bootstrap with BMC or even a flash drive and skip the whole network anyway.

Finally, you can reduce risk if you only bootstrap a minimal executable which itself has a robust bootstrapping mechanism. In the post, they're jumping to iPXE from UEFI so the concern would be loading an old iPXE version.

Post reply on HN