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 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
> 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, 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?