Facilitate Secure Boot

[JamiKettunen]

I'd be interested in running self-signed kernel, initramfs etc on my laptop with secure boot enabled. https://github.com/Foxboron/sbctl certainly is a projcet of interest, and once a working setup is found getting something up on https://chimera-linux.org/docs/ would be really awesome :)

[q66]

we can probably do this without sbctl (which couldn't be officially supported as golang compiler is in contrib, and it would be nice to have an official way to do this - that's not to say it cannot be an alternative available approach installable through contrib though)

to make secure boot useful, you pretty much need a few things:

1) the part of the system that is outside of the trusted boot chain must be encrypted; this includes /boot (encryption of which is normally useless without secure boot because it should not contain any private data, but it's in your boot path and you need to make sure your initramfs or your kernel has not been tampered with) 2) the actual boot chain must be trusted by signing everything within efi system partition with your key 3) you need a way to manage the keys

point 1 is done with LUKS, or ZFS encryption, or whatever

there are a few approaches for point 2:

1) use a third party bootloader like GRUB; this requires support from said bootloader, and can be a pain (e.g. with GRUB because of restrictions on what kinda encrypted drives it can open, and you need to make sure you don't need to enter your password twice somehow, e.g. by using a key instead of passphrase for second stage open) 2) use efistub, and make the efistub a unified kernel image, so that it contains both the kernel and initramfs; then sign the whole image, and have it be your uefi executable

sbctl appears to use the unified kernel image approach

it is possible to create unified kernel images manually; for that you need a UEFI kernel boot stub binary (e.g. systemd-boot provides one, we could package that or a portion of that), objcopy, and a bit of know-how - we could create our own ukify program to create such images more simply

as for signing and key management, there appear to be ways to do this, one that i can see is https://git.kernel.org/pub/scm/linux/kernel/git/jejb/sbsigntools.git/

the rest is mostly just putting it together, possibly adding e.g. some kind of kernel hook that will do the right setup so that one does not have to manually fiddle with things on every kernel update, and that's the hard part that would need correctly designing, because it needs to be done so that it is configurable to support a variety of cases and also does not conflict with other approaches and so on

i probably will not be doing this, but if somebody feels like tackling that, i can at least provide review and so on to steer it towards something acceptable

[linux-leo]

About point 1, what about checking the checksums of the files in the /boot partition, something documented at the FAQ page for the limine bootloader?

[q66]

some more observations:

1) sbctl just uses systemd-boot efi stubs to generate its uki bundles, so technically it does not help us at all with having something portable (even disregarding golang) - i.e. even if we were to add it, we'd need to package systemd-boot first (and then secure boot support is not far away even without sbctl, we'd just need sbsigntools and possibly some other minor pieces; as for a uki generator, that's the trivial part) 2) i was messing with trying to get systemd-boot built today out of curiosity (and because it might be useful to have it as an option) and as our toolchain is, it's a major pain; there are various issues, such as: 1) https://github.com/systemd/systemd/issues/19005 2) https://github.com/systemd/systemd/issues/13800 3) at least our musl environment requires additional workarounds to deal with some c stdlib conflicts when dealing with the efi-side code, e.g. wrt function redeclarations as well as the fact that the efi-side abi uses narrow wchar (16-bit) 4) neither elftoolchain objcopy nor llvm-objcopy supports the features that the build system requires to get the efi bits properly generated, so we'd need to use binutils there, or find an acceptable workaround

some of these issues will also apply to e.g. refind and possibly other projects, if we were to add that

[ghost]

Sbctl makes creating and enrolling keys really easy, i say it should atleast be provided as an alternative, ill be glad if someone packages it

[ghost]

Once we have a efistub and something that can sign efi images, be it in main or contrib, it would be nice to see clevis packages to allow automatic unlocking of encrypted partitions.

[q66]

what do you mean? you can already have disk encryption with luks or zfs, including decryption on boot

[ghost]

I meant automatic decryption of volumes based using the TPM chip. This can allow for automatic decryption if certain conditions, such as secure boot being enabled, are met.

I tried packaging clevis and it's missing dependencies, but was met with an error when building the man pages of one of the dependencies.

[q66]

feel free to submit your work, if there's stuff you can't figure out we can probably work it out somehow (or you can ask on irc/matrix)

[q66]

i've added systemd-boot and with it its efi stubs in 69ee7a6b24d72b86f71848b4a41251aba4ce0be4; that means the main blocker is gone

[tulilirockz]

Managed to boot to the initramfs using a sbctl bundle-generated UKI image! It did blow up because I didnt configure it right, but it surely does work fine