[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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/


>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


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


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: