Re: Where are we with SB? What's missing?
On Sat, Oct 06, 2018 at 01:33:36PM +0200, Ansgar Burchardt wrote:
>On Fri, 2018-10-05 at 19:01 +0100, Steve McIntyre wrote:
>> AFAICS we're *just* about there with Secure Boot, but we've not
>> turned
>> it all on. I was (naïvely?) hoping that we'd be able to get it all
>> finished with the final push at DebConf. We came tantalisingly
>> close... What's left to finish? Are there any blockers remaining, or
>> are we just at the stage of everybody waiting on each other to say
>> "go"?
>
>I managed to try the Secure Boot enabled kernel on a laptop. Besides
>some problems due to `efibootmgr` reporting errors (out of space) and
>having to fiddle around to enroll the test signing key, my laptop now
>booted with Secure Boot enabled (via shim -> grub2 -> linux) \o/
\o/
>Short howto, hopefully I didn't forget anything:
> - You need a second way to boot the system!
> - Grab test cert from src:linux,
> debian/certs/test-signing-certs.pem
> - Convert to DER:
> openssl -inform pem -in test-signing-certs.pem -outform der -out /boot/efi/EFI/debian/testcert.der
> - Install shim-signed, grub-efi-amd64-signed, linux-image-4.19.0-rc6-amd64 from experimental.
> - In /boot/efi/EFI/debian:
> - cp grubx64.efi grubx64.efi.ori
> - cp mmx64.efi grubx64.efi
> - Enable Secure Boot and reboot; should boot into MOK (mmx64.efi)
> - Enroll testcert.der from above
> - Boot via rescue (might need to disable secure boot)
> - Restore grub2: cp grubx64.efi.ori grubx64.efi
> - Reboot with Secure Boot
Awesome!
>There are still two things I would like to look at:
>
>Ben suggested adding an entry to the signing request to make sure we do
>never create a trust chain from the production key to any non-
>production key[1]. Though I wonder if the kernel really needs to have
>an embedded key at all? On Ubuntu it seems to use the same set of keys
>already trusted by UEFI (including those enrolled by users). This way
>DKMS modules can be signed by end users (after creating and enrolling a
>local signing key).
Pass. Ben?
>I would like to solve this before switching to production keys.
>
> [1] https://wiki.debian.org/SecureBoot#Describing_the_trust_chain
>
>We still need to look how and when to publish the logs of what we
>signed. However we should make sure not to publish records for
>security updates too early: when kernel modules build reproducible,
>most shouldn't change during a security update and this would allow to
>see which module is affected by undisclosed security issues (unless
>modules include the kernel version if which case they all change; I
>didn't check). The lazy way out would be to only publish logs with a
>month delay or so.
>
>This shouldn't be a blocker though.
Right.
I have one more thing to mention. From talking to the core EFI folks,
they'd also like us to shift to a newer version of shim before too
long. It would be nice to do that before Buster release, But it's
*really* not a blocker for us enabling things today.
--
Steve McIntyre, Cambridge, UK. steve@einval.com
"Every time you use Tcl, God kills a kitten." -- Malcolm Ray
Reply to: