(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

Hey Faidon,

Control: tags -1 +wontfix

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.

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.

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 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. :-(

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 :/

Right... That makes sense.

(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]:

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