Bug#930217: Please provide support for alternative network bootloaders

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

Bug#930217: Please provide support for alternative network bootloaders

Faidon Liambotis-2
Package: src:shim
Version: 15+1533136590.3beb971-7
Severity: wishlist

(I'm Cc'ing the syslinux and iPXE maintainers here for their information
and to seek their opinion. I haven't discussed this matter with neither
of them and do not speak for them.)

Currently, the only way to network boot a Debian EFI system with Secure
Boot via shim is to use GRUB, as this is the only combination that's
SB-signed (bootnetx64.efi even hardcodes grubx64.efi). This is what
Debian's own netboot.tar.gz ship with as well

However, GRUB's TCP/IP + DNS + HTTP stack is... to put it politely,
severely lacking. I've managed to crash it[1], find serious TCP[2] or
HTTP[3] implementation bugs, run into very basic limitations (e.g. on
dual-stack hostnames[5]), all within a few hours. For some reason
they've decided to build a TCP/IP stack from scratch (rather than use
EFI's, or something like lwIP), but their code, to this day, has
comments like "/* FIXME: overflow. */". I've tried to build a sane
netboot configuration with GRUB, and work around its bugs, but
ultimately failed -- it's just too buggy for anything but just booting a
kernel + initramfs, and if even that.

1: 52408aa94604466bdd80f48fa8d68378a1ffab31
2: https://savannah.gnu.org/bugs/?56391
3: https://savannah.gnu.org/bugs/?49531
4: https://savannah.gnu.org/bugs/?56390

Despite these having been reported upstream, I don't have high hopes;
their bug tracker is a dumpster fire. Noone is responding to old or new
bugs, no matter their severity. I was looking into SMBIOS support as
well, and it looks someone has written a working patch that other
distributions ship; that person has been submitting it once a year since
2013, and never received a response. I filed this as a bug in their bug
tracker[5] but that has not received a response either.

5: https://savannah.gnu.org/bugs/?56164

All in all, I think there are two compounding issues here: 1) the GRUB
project's overall health 2) network boot not being a priority for them.

However, this being free software, there are alternatives :) The two
most popular network bootloaders are:

1) SYSLINUX (syslinux.efi specifically): this is much more restricted in
terms of features, but good enough for many use cases and more reliable
than GRUB. syslinux.efi uses the EFI stack's TCP/IP implementation
(Tcp4ServiceBindingProtocol) and doesn't roll its own, which at least
makes it more secure than GRUB's (albeit without IPv6 support right
now). The other advantage here is that this is fully compatible with a
PXELINUX config which most people are used to. Debian's own d-i images
ship with such a configuration to this day and this could be an
out-of-the box alternative.

2) iPXE: this is widely used in both PXE and EFI configurations. QEMU is
even using it to netboot by default. It has a flexible configuration
language, lots of features out of the box, and a much, much, much
cleaner codebase than GRUB.  Their documentation is far more superior
too. They even have a page with instructions for how one can submit iPXE
to Microsoft to get it SB-signed[6] and there are reports on the web
that Microsoft has actually signed[7] of their versions.

6: http://ipxe.org/appnote/etoken
7: https://twitter.com/ipxe/status/331176286972157953

The request here is for Debian w/ Shim to support an alternative to GRUB
out of the box, and to sign iPXE and/or syslinux. These are alternatives
that are clearly superior in features, stability -and, dare I say,
security- over GRUB and Debian shouldn't artificially limit our choices
to just one.

An alternative to this proposal would be for Debian to submit e.g. iPXE
separately to Microsoft for signatures and not use this in combination
with shim. I believe this doesn't fit with the overall strategy that
Debian and other distributions have chosen around Secure Boot with shim,
but... I am really not an expert :)

Thanks for the consideration!

Best,
Faidon

Reply | Threaded
Open this post in threaded view
|

Bug#930217: Please provide support for alternative network bootloaders

Steve McIntyre
Hey Faidon,

Control: tags -1 +wontfix

On Sat, Jun 08, 2019 at 03:43:37PM +0300, Faidon Liambotis wrote:

>Package: src:shim
>Version: 15+1533136590.3beb971-7
>Severity: wishlist
>
>(I'm Cc'ing the syslinux and iPXE maintainers here for their information
>and to seek their opinion. I haven't discussed this matter with neither
>of them and do not speak for them.)
>
>Currently, the only way to network boot a Debian EFI system with Secure
>Boot via shim is to use GRUB, as this is the only combination that's
>SB-signed (bootnetx64.efi even hardcodes grubx64.efi). This is what
>Debian's own netboot.tar.gz ship with as well
>
>However, GRUB's TCP/IP + DNS + HTTP stack is... to put it politely,
>severely lacking. I've managed to crash it[1], find serious TCP[2] or
>HTTP[3] implementation bugs, run into very basic limitations (e.g. on
>dual-stack hostnames[5]), all within a few hours. For some reason
>they've decided to build a TCP/IP stack from scratch (rather than use
>EFI's, or something like lwIP), but their code, to this day, has
>comments like "/* FIXME: overflow. */". I've tried to build a sane
>netboot configuration with GRUB, and work around its bugs, but
>ultimately failed -- it's just too buggy for anything but just booting a
>kernel + initramfs, and if even that.
>
>1: 52408aa94604466bdd80f48fa8d68378a1ffab31
>2: https://savannah.gnu.org/bugs/?56391
>3: https://savannah.gnu.org/bugs/?49531
>4: https://savannah.gnu.org/bugs/?56390
>
>Despite these having been reported upstream, I don't have high hopes;
>their bug tracker is a dumpster fire. Noone is responding to old or new
>bugs, no matter their severity. I was looking into SMBIOS support as
>well, and it looks someone has written a working patch that other
>distributions ship; that person has been submitting it once a year since
>2013, and never received a response. I filed this as a bug in their bug
>tracker[5] but that has not received a response either.
>
>5: https://savannah.gnu.org/bugs/?56164
>
>All in all, I think there are two compounding issues here: 1) the GRUB
>project's overall health 2) network boot not being a priority for them.

There's a fair amount of work going on in Grub, but yes - it looks
like nobody's tending their bug tracker. :-(

Network booting is clearly not the highest priority for the current
developers, but I'm sure that can be fixed with developer effort. It
works well enough for common cases, in my experience - I've just been
doing testing of this for #928750.

>However, this being free software, there are alternatives :) The two
>most popular network bootloaders are:
>
>1) SYSLINUX (syslinux.efi specifically): this is much more restricted in
>terms of features, but good enough for many use cases and more reliable
>than GRUB. syslinux.efi uses the EFI stack's TCP/IP implementation
>(Tcp4ServiceBindingProtocol) and doesn't roll its own, which at least
>makes it more secure than GRUB's (albeit without IPv6 support right
>now). The other advantage here is that this is fully compatible with a
>PXELINUX config which most people are used to. Debian's own d-i images
>ship with such a configuration to this day and this could be an
>out-of-the box alternative.
>
>2) iPXE: this is widely used in both PXE and EFI configurations. QEMU is
>even using it to netboot by default. It has a flexible configuration
>language, lots of features out of the box, and a much, much, much
>cleaner codebase than GRUB.  Their documentation is far more superior
>too. They even have a page with instructions for how one can submit iPXE
>to Microsoft to get it SB-signed[6] and there are reports on the web
>that Microsoft has actually signed[7] of their versions.
>
>6: http://ipxe.org/appnote/etoken
>7: https://twitter.com/ipxe/status/331176286972157953
>
>The request here is for Debian w/ Shim to support an alternative to GRUB
>out of the box, and to sign iPXE and/or syslinux. These are alternatives
>that are clearly superior in features, stability -and, dare I say,
>security- over GRUB and Debian shouldn't artificially limit our choices
>to just one.

There's no way we're going to sign syslinux, I'm afraid - there has
been no support added for locking down boot (i.e. only booting a
signed kernel). Without that, Secure Boot would be a total joke. And
if you're worried about Grub development, I'd be even more worried
about syslinux. I'm on both mailing lists, and there's massively more
development happening in the Grub world.

>An alternative to this proposal would be for Debian to submit e.g. iPXE
>separately to Microsoft for signatures and not use this in combination
>with shim. I believe this doesn't fit with the overall strategy that
>Debian and other distributions have chosen around Secure Boot with shim,
>but... I am really not an expert :)

iPXE at least appears to be currently under development, but again I
don't see any obvious lockdown patches at all. Feel free to correct me
if you know of any work for that - I've only had a cursory look. SB
without restricting loading of kernels etc. is pointless.

>Thanks for the consideration!

Thanks for asking about this, but I think the answer has to be "no"
for now. If you're genuinely being blocked by Grub networking bugs,
then we'll need to fix those bugs. Or disable Secure Boot. Sorry. :-(

--
Steve McIntyre, Cambridge, UK.                                [hidden email]
You raise the blade, you make the change... You re-arrange me 'til I'm sane...

Reply | Threaded
Open this post in threaded view
|

Bug#930217: Please provide support for alternative network bootloaders

Faidon Liambotis-2
On Wed, Jun 19, 2019 at 04:54:33PM +0100, Steve McIntyre wrote:
> There's a fair amount of work going on in Grub, but yes - it looks
> like nobody's tending their bug tracker. :-(
>
> Network booting is clearly not the highest priority for the current
> developers, but I'm sure that can be fixed with developer effort. It
> works well enough for common cases, in my experience - I've just been
> doing testing of this for #928750.

Depends on the definition of "common case" I suppose... Attempting to
netboot, reboot and netboot again in succession (without waiting 1-4
minutes) throws GRUB's TCP stack into an unrecoverable mayhem and
results into a user-visible "connection timed out". Easily reproducible
e.g. with QEMU.

Not to mention the potentially exploitable overflows :/

> There's no way we're going to sign syslinux, I'm afraid - there has
> been no support added for locking down boot (i.e. only booting a
> signed kernel). Without that, Secure Boot would be a total joke. And
> if you're worried about Grub development, I'd be even more worried
> about syslinux. I'm on both mailing lists, and there's massively more
> development happening in the Grub world.

Right... That makes sense.

> >An alternative to this proposal would be for Debian to submit e.g. iPXE
> >separately to Microsoft for signatures and not use this in combination
> >with shim. I believe this doesn't fit with the overall strategy that
> >Debian and other distributions have chosen around Secure Boot with shim,
> >but... I am really not an expert :)
>
> iPXE at least appears to be currently under development, but again I
> don't see any obvious lockdown patches at all. Feel free to correct me
> if you know of any work for that - I've only had a cursory look. SB
> without restricting loading of kernels etc. is pointless.

(disclaimer: I'm -at best- an SB novice)

iPXE does support validating signatures[1][2] but not with the EFI
signing protocol and not without using a custom embedded script. More
importantly, however, I found this explanation at the iPXE mailing
list[3]:
> iPXE loads the binary and then calls the firmware LoadImage - meaning
> that it is up to the firmware LoadImage function to validate the
> signature, and return error to iPXE if the signature is not valid.
> iPXE itself does not have any code to check the signature, and by
> using the firmware to check it, it isn't needed.  In this case it
> seems that the image is not valid according to Firmware functions?
> Could you validate that the kernel loads fine from the efi_shell, or
> without having iPXE in between?

I suppose that means that a shim -> iPXE -> Linux load would be
pointless in this case, unless one were to construct a shim -> iPXE ->
shim -> Linux chain. Would that even work, and would it be sensible?

Upstream has mentioned that they have gotten Microsoft to sign some of
their builds[4], and have included an "sb" variant in their buildsystem
that disabled dubious subsystems like NFS and 802.11. So I suppose
Microsoft does consider this secure enough and thus so could Debian?

Thanks!
Faidon

1: http://ipxe.org/crypto#code_signing
2: http://ipxe.org/cmd/imgtrust
3: http://lists.ipxe.org/pipermail/ipxe-devel/2018-September/006288.html
4: http://lists.ipxe.org/pipermail/ipxe-devel/2017-December/005924.html