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
