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.
Introduction to UEFI HTTP(s) Boot with QEMU/OVMF
11–20 of 35 posts
Re: Introduction to UEFI HTTP(s) Boot with QEMU/OVMF
#12Having 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…
> > 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 gone to the trouble to modify software to inject malware would certainly happily serve it to you over TLS.
Re: Introduction to UEFI HTTP(s) Boot with QEMU/OVMF
#13Earlier quoted context omitted.
Secure boot is designed to verify software signatures. The UEFI bios might support loading software over https, but it isn't part of secure boot. Secure boot would verify any kernels/etc loaded from https.
> 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.
Re: Introduction to UEFI HTTP(s) Boot with QEMU/OVMF
#14Having 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.
Re: Introduction to UEFI HTTP(s) Boot with QEMU/OVMF
#15BTW 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 network. I had especially expected better from Dell but the experience is... lacking.
Re: Introduction to UEFI HTTP(s) Boot with QEMU/OVMF
#16To 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.
It works on the majority of UEFI implementations
1. Just a matter of a boot entry. However adding the boot entry is not trivial: efibootmgr used to have implementation which have been reverted (it was incomplete, works only with full device path unlike just MAC which the original code added).
I don't know any utilities to do that, ended patching efibootmgr myself.
Learned about it from this talk: https://youtu.be/EtGhHCr3VLE?t=567
2. HTTP Boot is also available as a DHCP option 67 without boot entry:
* https://github.com/tianocore/tianocore.github.io/wiki/HTTP-B...
* https://documentation.suse.com/sles/15-SP6/html/SLES-all/cha...
Re: Introduction to UEFI HTTP(s) Boot with QEMU/OVMF
#17Having 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…
> > 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.
Re: Introduction to UEFI HTTP(s) Boot with QEMU/OVMF
#18BTW 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…
> 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 there's all the other firmware stuff.
Unfortunately, there is nothing in the "physical world" that comes even close to USB-CDC in its versatility.
Re: Introduction to UEFI HTTP(s) Boot with QEMU/OVMF
#19Having 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…
NBD (over TLS) would be even better because it loads on demand. You could ship large full-featured OS images and only the parts/features you used would be loaded. One day when I'm retired I plan to add this to OVMF.
Re: Introduction to UEFI HTTP(s) Boot with QEMU/OVMF
#20Having 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…
> > 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).