Re: Bug#930217: Please provide support for alternative network bootloaders
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. steve@einval.com
You raise the blade, you make the change... You re-arrange me 'til I'm sane...
Reply to: