[arch-dev-public] Arch Linux Secure Boot support, get it done ; )

[Morten Linderud]

On Wed, Feb 02, 2022 at 12:20:19PM +0100, Tobias Powalowski via arch-dev-public wrote:
> Hi guys,
> next topic to step up: Secure Boot support
> I wanted to bring this up to the mailing list to collect all info about the
> status of SB support.
> There are different approaches on how to implement SB.
> My question first: Do we want a signed shim for Arch Linux?
> If yes, how to achieve this? We should make a process in our infrastructure
> and document what needs to be done and who does it.
> Morten would you please add your thoughts about this topic on the ML, i
> think you are most into SB on linux.

Quick notes from me!


# Signed SHIM

First of we need to have a signing solution for this. My idea has been to
piggy-back on the existing work on the signing-enclave. However it's current
focus is GnuPG and I need something which can support x509 certificates and
preferably PKCS11 for hardware tokens.

I think having a separate POC for this and later folding it into the
signing-enclave is a good options as well.

Once we have a key we can embed into the shim, we can build a shim package and
submit it for review to Microsoft.

https://github.com/rhboot/shim-review

Once this is signed and approved by Microsoft we can provide our own
"shim-signed" package.


# Packaging

Next up is how to solve the packaging? We need to sign the bootloader we want to
support with our MOK which is embedded into our signed shim. This implies
extracting recent packages, get the binaries and sign them.

The signed packages we would end up with would look something like:

* grub-signed
* systemd-boot-signed
* refind-signed
* fwupd-signed

But we need to figure out how this process should be done. I'm not super
interested this being dependant on a single Developer/Packager. And we would
preferably want all of these packages reproducible.

The idea could be to make detached signature's and fetch the package from the
archive with the signature and construct the signed binary in our package. This
would mostly solve that issue.

Here is a mock up of how Debian has intended to solve this:
https://wiki.debian.org/SecureBoot/Discussion#Earlier_proposed_signing_architectures

There is also an entire SBAT thing we need to document and properly administer
across our EFI binaries.
https://github.com/rhboot/shim/blob/main/SBAT.md


# Installation

Now, how do we actually work this into the installation process? With the above
we can have archiso boot on a Secure Boot enabled system. But we do not control
how users install their systems, and I think it would be overzealous to enforce
this on new installation?

So do we update the wiki for accounting for secure boot? How do we explain what
needs to be done so people are not installing a system that won't boot because
of Secure Boot?


# RFC

I think this entire process should be an RFC along with how we want to
accomplish each step.

https://gitlab.archlinux.org/archlinux/rfcs/

My main focus is mostly going to be around the Git package migration but I have
been tempted writing up a POC when I have a weekend. It would mostly be to make
an example signing solution and some package examples.

-- 
Morten Linderud
PGP: 9C02FF419FECBE16
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <https://lists.archlinux.org/pipermail/arch-dev-public/attachments/20220202/0af83008/attachment.sig>