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