mbox series

[bug#68524,0/2] Support root encryption and secure boot.

Message ID cover.1705465384.git.lilah@lunabee.space
Headers show
Series Support root encryption and secure boot. | expand

Message

Lilah Tascheter Jan. 17, 2024, 4:23 a.m. UTC 
Primarily adds a new bootloader, uefi-uki-bootloader, and an auxilliary form,
uefi-uki-signed-bootloader. These use isolated fragments of the systemd project
(particularly the systemd-stub UEFI stub and supporting ukify tool) to install
combined kernel/arguments/initrd images to the EFI system partition. The
built-in UEFI boot manager can then deal with boot selection. While this does
require copying files from the store to the partition, it makes up for it in two
important ways:

1. Proper encrypted root support! GRUB is really fucking slow at decrypting the
store in my experience, and it's annoying to have to enter in the root password
twice. Since the kernel is loaded directly from the system partition, the first,
and only, LUKS password entry is in the initrd. Also wholly bypasses GRUB not
supporting LUKS2 (or, at least, having bad issues with it on Guix).

2. Secure boot support! It's set up assuming the user has already created the
necessary keys (typically, in /root, as they should only be root-accessible).
Passing the paths to the db cert and key to uefi-uki-signed-bootloader will then
automatically sign the entire bootloader image. In combination with root
encryption, assuming a functioning motherboard UEFI installation, this should
fully secure Guix's boot chain.

This is ported from my personal channel, so uefi-uki-bootloader has been tested
for months. The main drawback is lack of kernel generation rollback in the case
of a botched upgrade, so I've been keeping around a manually-copied backup uki
image, but I haven't had any troubles with it so far. I have just verified
uefi-uki-signed-bootloader properly functions and boots in secure boot user
mode.

All in-system testing has been done on my channel, so the porting process may
have had issues, but I did make sure the added packages compile, and there
aren't any miscopies.

No clue how this works on non-x64 systems. I don't think there's enough ARM UEFI
systems in existance for it to matter that much anyway.

Thanks!

Lilah Tascheter (2):
  gnu: bootloaders: Add uki packages.
  gnu: bootloaders: Add uefi-uki-bootloader.

 doc/guix.texi                |  35 +++++++++---
 gnu/bootloader/uki.scm       | 106 +++++++++++++++++++++++++++++++++++
 gnu/packages/bootloaders.scm |  94 +++++++++++++++++++++++++++++++
 3 files changed, 227 insertions(+), 8 deletions(-)
 create mode 100644 gnu/bootloader/uki.scm


base-commit: 21f5d20d68e0359f8111ccb936905649c70db9c1

Comments

Lilah Tascheter March 8, 2024, 8:09 a.m. UTC | #1 
nah, what I meant by that is instead of entering your password while
you're booted into grub, you enter it while booted into your initrd.
either way nothing touches the disk.
Nikolaos Chatzikonstantinou March 8, 2024, 10:41 a.m. UTC | #2 
Great, thank you for clarifying. This is awesome work. Does it mean
however that Guix becomes tied to systemd in some way when this
feature is used? Or is the feature sufficiently isolated that no
systemd process takes place?

I've also looked briefly into this from another angle, trying to
either patch GRUB or to use kexec and boot from a USB. I'm glad that
you were able to do this, thanks a lot!

Regards,
Nikolaos Chatzikonstantinou
Lilah Tascheter March 23, 2024, 7:40 p.m. UTC | #3 
sorry for the late responses; I don't actually get sent your replies
unless you cc me.

and yeah don't worry it's isolated. there's only two bits of systemd
used, systemd-boot-stub and ukify. ukify is pretty much just a single
python script, and systemd-boot-stub is just a bit of code tacked on to
the boot process to handle combining the kernel, args, and initrd
together. no daemons or code past the bootloader at all!

of note I'm currently in the process of rewriting the entire guix
bootloader stack to make this work a Lot nicer. sooo hopefully that
gets finished soon.
Nikolaos Chatzikonstantinou March 24, 2024, 9:38 a.m. UTC | #4 
On Sat, Mar 23, 2024 at 3:40 PM Lilah Tascheter <lilah@lunabee.space> wrote:
> and yeah don't worry it's isolated. there's only two bits of systemd
> used, systemd-boot-stub and ukify. ukify is pretty much just a single
> python script, and systemd-boot-stub is just a bit of code tacked on to
> the boot process to handle combining the kernel, args, and initrd
> together. no daemons or code past the bootloader at all!
>
> of note I'm currently in the process of rewriting the entire guix
> bootloader stack to make this work a Lot nicer. sooo hopefully that
> gets finished soon.

Very exciting! I am looking forward to looking at the code.

Regards,
Nikolaos Chatzikonstantinou