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

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
  

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.
  

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
  

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.
  

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
  

Hi all!

No clue if this patch series is still being worked on, however I have been keeping an eye on this (want to migrate away from GRUB because of decryption speed and integrity reasons). Good news, I've successfully added these patches on a local channel I have and everything still works, with little modifications (this has been an on and off process over the past month or so because I've been busy, so my memory of changes made may be fuzzy). However, I did notice a bug. When performing a fresh installation, the bootloader install will always fail since it assumes "/boot/efi" as the base "script-path". This assumption is false due to the installer placing the system being installed at "/mnt/boot/efi".

Outside of that, is a new rewrite of the boot system still being worked on? What kinds of things are we looking for to get UKIs merged? Should I start/continue a thread on guix-devel? I'd like to help where I can.
  

Hey!

> When performing a fresh installation, the bootloader install will >
always fail since it assumes "/boot/efi" as the base "script-path".
Yeah, sorry, limitation of the current system. Speaking of, though...

The rewrite has been posted! The new patch series is at
https://issues.guix.gnu.org/72457 which also subsumes this series, so
I'll close this one in favor of it.

Thanks y'all!
  

On Thu, Aug 15, 2024 at 9:15 AM Lilah Tascheter <lilah@lunabee.space> wrote:
>
> Hey!
>
> > When performing a fresh installation, the bootloader install will >
> always fail since it assumes "/boot/efi" as the base "script-path".
> Yeah, sorry, limitation of the current system. Speaking of, though...
>
> The rewrite has been posted! The new patch series is at
> https://issues.guix.gnu.org/72457 which also subsumes this series, so
> I'll close this one in favor of it.

Congratulations. This is great!

Regards,
Nikolaos Chatzikonstantinou
  

You can't change kernel parameters when you boot uki bootloader.

GRUB allows you to change kernel parameters before boot.

I wish guix installed kernel and initrd and grub.cfg in /boot. Then, grub doesn't need a password, and decrypting encrypted file systems will be a lot faster with grub.
  

I propose writing grub.cfg instead of modifying nvram.

1. Modifying nvram whenever there are changes to kernel images will increase wear and tear on nvram. If grub loads uki, then nvram lifespan will increase.

2. kernel arguments should go to both grub.cfg and uki because uki arguments are passed to kernel in the absence of secure boot. I'd like to be able to change kernel arguments in grub for debugging and troubleshooting.

Thus, the bootloader can be called grub-uefi-uki-bootloader and grub-uefi-uki-signed-bootloader.