Re: Bug#930217: Please provide support for alternative network bootloaders
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
Reply to: