naturalmovement
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.
|
> my-boot
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.
|
> > mschuster91
> 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.[1]
https://packages.debian.org/forky/firmware-mediate
k[2]
https://packages.debian.org/forky/firmware-intel-m
isc
|
> > > xxpor
I'd guess that the mediatek blobs are exactly
64k, and mostly 0s?
|
> > naikrovek
> slow loadingNot 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 <fqdn> 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.
|
nijave
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
|
> naturalmovement
> > adding the TLS layer brings back the missing
integrityA 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.
|
> > rwmj
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).
|
> > > naturalmovement
I can guarantee you with nearly 100% certainty
that UEFI TLS clients are bound to be buggy
garbage broken in not-insignificant ways.
|
> > eggnet
TLS also allows for the contents of a boot image
to be hidden from others.
|
> > > naturalmovement
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.
|
> pzmarzly
> The range of things that can run an http server is
much bigger than tftpDon'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.
|
> > pdmccormick
Thank you for sharing this tidbit. It looks like
this may have been fixed?
https://github.com/tianocore/edk2/blob/master/Netw
orkPkg/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!
|
> LooseMarmoset
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.
|
> > RulerOf
That was the point as I read it. Payload signature
verification is a good and sometimes desirable
alternative to transport encryption when the
payload itself isn't secret.Highly-cacheable
resources like game and OS updates are often
intentionally delivered over http as signed
payloads to facilitate middlebox caching.
|
> > naturalmovement
> Secure boot is designed to verify software
signaturesaka 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.
|
> > > robertlagrant
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.
|
> rwmj
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.
|
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.
|
> wmf
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.
|
noodlesUK
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.
|
> ValdikSS
It works on the majority of UEFI implementations1.
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=5672. 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-a
ll/cha...
|
> nijave
There's still the tftp->ipxe->http->??? path. TFTP
only needs to serve a 300kb file which can then switch
to more robust transport like http for the
kernel/OSYou could bypass that by shipping iPXE on USB
thoOn metal you also commonly have a BMC so generally
that lets you attach an ISO or other storage you can
boot from to bypass UEFI primitive PXE. This is
probably the biggest one--use BMC functionality
instead of UEFI PXEAt home, I use JetKVM or GL.iNet
Comet network KVM to bootstrap commodity hardware
without BMC (by attaching an ISO). Probably could make
a cheap commodity device with Raspberry Pi Zero that
does that same thing at lower cost although at that
point you're back to "just use USB storage"
|
> wmf
All recent servers support HTTP boot.
|
> zcw100
You can use iPXE https://ipxe.org/
|
jeffrallen
Hey, I'd say "hire this guy", but we already did. This is
an excellent write up of excellent work by an excellent
colleague. Thanks yadutaf!
|