Created attachment 906330 [details] proposed patch for binhost For some time now the prebuilt dist-kernel gentoo-kernel-bin has been built with signed kernel modules and kernel images. This is useful for users who would like this bit of extra verification without going through the trouble of generating and managing a new openssl key locally. However, for this to be useful on systems with Secure Boot enabled a crucial component is still missing: the bootloader. If the user has to generate a new key to sign the bootloader anyway then distributing the kernel in a signed form becomes less useful. The current solution to this problem would be to skip the bootloader and load the kernel directly from UEFI (efistub booting). This however does not work on all machines due to UEFI bugs/quirks. I therefore propose to distribute on the binhost binpkgs of bootloaders that are pre-signed (i.e. built with USE=secureboot). Concretely this would involve the following packages: - sys-boot/grub[secureboot] - sys-apps/systemd[kernel-install,boot,secureboot,ukify] (for systemd) - sys-apps/systemd-utils[kernel-install,boot,secureboot,ukify] (for OpenRC) - sys-boot/shim[secureboot] (for Secure Boot without touching UEFI DB) - sys-boot/mokutil (for managing the shim MOK list) Ukify is not strictly required but I think it makes sense to add this as well so the whole chain towards an UKI is achievable from binpkgs. I propose to stick with only systemd-boot and grub for now (other examples of bootloaders with USE=secureboot are sys-boot/refind, sys-boot/elilo and sys-boot/syslinux[uefi]). This will also pull in a new dependency: app-crypt/sbsigntools to perform the signing. And it will require generating a new PEM format openssl key on the build host. Attached is a patch that I think will do the job. It only makes the changes for amd64, but it might make sense to make the same changes for arm64 as well. What do you think?
It is unnecessary to add systemd to world on gnome, probably, since it is part of @system? And same for systemd-utils on the openrc profiles as it is installed by virtual/tmpfiles. On this note, it appears that you are enabling variants for both openrc (builds systemd-utils) and server (builds grub) but I think this is unnecessary? You could do both in the server build. It too has systemd-utils installed. This is slightly beneficial as we avoid having to do dependency calculations for @world twice. ... I'm guessing your inclusion of the make.conf variables to profiles that don't build any variants (kde) is "just in case" it ever enables USE=secureboot in the future? Hmm.
Created attachment 906397 [details, diff] proposed patch for binhost v2 (In reply to Eli Schwartz from comment #1) > It is unnecessary to add systemd to world on gnome, probably, since it is > part of @system? And same for systemd-utils on the openrc profiles as it is > installed by virtual/tmpfiles. > > On this note, it appears that you are enabling variants for both openrc > (builds systemd-utils) and server (builds grub) but I think this is > unnecessary? You could do both in the server build. It too has systemd-utils > installed. This is slightly beneficial as we avoid having to do dependency > calculations for @world twice. Thanks, that makes sense, attached is v2 of the patch. > I'm guessing your inclusion of the make.conf variables to profiles that > don't build any variants (kde) is "just in case" it ever enables > USE=secureboot in the future? Hmm. Yeah the idea here was to retain the symmetry between the make.conf's and just in case it is needed there in the future.
Note, shim has stable versions, but mokutil does not (yet). Filed stable request here: Bug 941880
(In reply to Nowa Ammerlaan from comment #3) > Note, shim has stable versions, but mokutil does not (yet). Filed stable > request here: Bug 941880 Alright, resolved, now we have stable versions of all these packages. Regarding the impact on build times for the binhost: mokutil, shim and sbsigntools I'd consider negligible they are tiny and fast. The only significant ones on my list would be grub and systemd. To minimize the added build load we could also consider building these packages only with USE=+secureboot instead of using the variants mechanism to build binpkgs for both configurations. Let me know what you think. One more thing I forgot before, in addition to generating a new PEM openssl key for this signing, we should also distribute the accompanying DER format certificate to users so they can include it in their MOK list or UEFI DB. The most straightforward way to do this would be some new package in the sec-keys/ category. Or alternatively, maybe we can simply re-use the key that we already use to sign the kernel images and kernel modules for gentoo-kernel-bin, the certificate belonging to that key is already distributed via the gentoo-kernel-bin package.
(In reply to Nowa Ammerlaan from comment #4) > Regarding the impact on build times for the binhost: mokutil, shim and > sbsigntools I'd consider negligible they are tiny and fast. The only > significant ones on my list would be grub and systemd. To minimize the added > build load we could also consider building these packages only with > USE=+secureboot instead of using the variants mechanism to build binpkgs for > both configurations. Let me know what you think. The time spent is an acceptable cost if it results in beneficial functionality. I was concerned above about "doing the same thing twice", but it was a minor nitpick. We definitely want to continue: - doing two different things, once each - distributing packages for the default USE flags which most people have installed. ;) ... The main concern is actually that we need to think about the ramifications of having and handling private key material on automated build machines which are ideally supposed to be somewhat ephemeral. (In reply to Nowa Ammerlaan from comment #4) > Or alternatively, maybe we can simply re-use the key > that we already use to sign the kernel images and kernel modules for > gentoo-kernel-bin, the certificate belonging to that key is already > distributed via the gentoo-kernel-bin package. ... but that is done by someone else, I thought? So we would need to coordinate that key across teams, and I personally know nothing about this, not even if that key is automatically generated on each build and deleted as part of "nothing up my sleeve" security, let alone whether that key is allowed to routinely sit on a cloud server. (Can you tell that I use gentoo-kernel and not the -bin? :)) Anyway, dilfridge was pondering the private key material question but hasn't responded regarding his thoughts yet. (*waves* any update?)
> (In reply to Nowa Ammerlaan from comment #4) > > Or alternatively, maybe we can simply re-use the key > > that we already use to sign the kernel images and kernel modules for > > gentoo-kernel-bin, the certificate belonging to that key is already > > distributed via the gentoo-kernel-bin package. > > ... but that is done by someone else, I thought? So we would need to > coordinate that key across teams, and I personally know nothing about this, > not even if that key is automatically generated on each build and deleted as > part of "nothing up my sleeve" security, let alone whether that key is > allowed to routinely sit on a cloud server. The gentoo-kernel-bin gpkgs are built in docker, the signing key is always the same and it's copied in from the host here: https://github.com/projg2/binpkg-docker/blob/3012fcc4e8eb1643ece96c785834d0296c632fdb/Dockerfile#L11C1-L11C42 mgorny and sam do the actual building of the gpkgs, they have access to the signing key and can maybe tell you more about how they manage it. > The main concern is actually that we need to think about the ramifications of > having and handling private key material on automated build machines which are > ideally supposed to be somewhat ephemeral. Yeah this is the difficult part. I'm not really sure in what way we can do this that is both secure and convenient. Just a though, maybe the binhost-update script could get the key from somewhere via ssh with some authentication? That would avoid having the key both on milou and jiji physically.
