Arch Linux

Ch4n3

Member

Registered: 2024-04-27

Posts: 3

Using UKI with Secure Boot, Full Disk Encryption, and BTRFS Snapshots

Hello,

I am planning to reinstall Arch using LUKS full-disk encryption and Secure Boot, with the root on BTRFS. I also want to create a separate and encrypted swap partition for hibernation, that will be unlocked using a key file. Currently, I am gathering information to establish a complete and consistent installation plan, in advance.

Since the swap partition needs to be unlocked during early userspace for resuming, the key file has to be included in the initrd image. To mitigate potential tampering, I'm considering using a UKI containing the initrd image with Secure Boot as described in the ArchWiki Unified kernel image article.

With the UKI on the ESP, does it imply the swap key file will be world-visible? Is it a security concern?

If so, as possible workarounds, I have been thinking about a couple of options: keeping the initrd image in encrypted /boot or keeping a single encrypted volume using LVM or a swap file. With the first solution, the chain of trust established by Secure Boot is broken. As for the second option, while LVM introduces an abstraction layer I prefer to avoid due to redundancy with BTRFS. As for using swap files, I am not very familiar with them and find swap partitions more reliable. I am also concerned about performance loss, even minimal.

Are there any other workarounds I should consider?

Finally, in the lights of my research, I could not find any information about default booting with a UKI while retaining the ability to boot from BTRFS snapshots using tools like grub-btrfs. Does using a UKI with Secure Boot prevent booting from snapshots?

Thanks in advance for your assistance.

Last edited by Ch4n3 (2024-04-27 21:29:15)

nl6720

The Evil Wiki Admin

Registered: 2016-07-02

Posts: 613

Re: Using UKI with Secure Boot, Full Disk Encryption, and BTRFS Snapshots

The easiest solution would be to use systemd-based mkinitcpio hooks since sd-encrypt can unlock multiple devices (i.e. both root and swap partitions in your case). This avoids complicating the partition structure and messing with encrypted /boot.
If you'll use the same passphrase for both encrypted devices, then you will only need to enter it once during boot.

V1del

Forum Moderator

Registered: 2012-10-16

Posts: 21,871

Re: Using UKI with Secure Boot, Full Disk Encryption, and BTRFS Snapshots

For the final question you'll not be able to boot snapshots where the kernel changed in between. You either exclude /usr/lib/modules from snapshots use a fat fallback image with all modules as your UKI or remember to reinstall the relevantly older kernel when intending to boot a snapshot

Ch4n3

Member

Registered: 2024-04-27

Posts: 3

Re: Using UKI with Secure Boot, Full Disk Encryption, and BTRFS Snapshots

Thank you both for your answers.

The easiest solution would be to use systemd-based mkinitcpio hooks since sd-encrypt can unlock multiple devices (i.e. both root and swap partitions in your case). This avoids complicating the partition structure and messing with encrypted /boot.
If you'll use the same passphrase for both encrypted devices, then you will only need to enter it once during boot.

Essentially that means using a single passphrase as with using a single LUKS container with LVM on it, but without LVM potential drawbacks. That is actually so simple that I have not thought about it and having only a single passphrase is a compromise I am willing to take.

For the final question you'll not be able to boot snapshots where the kernel changed in between. You either exclude /usr/lib/modules from snapshots use a fat fallback image with all modules as your UKI or remember to reinstall the relevantly older kernel when intending to boot a snapshot

If I understand well, `/usr/lib/modules` contains kernel modules and is updated with each kernel upgrade. Thus, creating a specific BTRFS subvolume for this directory would mean that every root snapshot I boot from would use the same kernel version. With a conveniently sized ESP, this is probably the most practical solution in most cases, to my mind. However, from my neophyte perspective, I suppose it could bring at least 2 major drawbacks:

• If an unstable kernel is the reason I need to boot from a previous snapshot, it defeats the purpose of using BTRFS snapshots in this specific case. Still, I should always have at least a fallback kernel installed like `linux-lts`.

• If I boot from a quite old snapshot, my system will end up in a partial update situation, with a mismatch between kernel and its modules versions, on one side, and packages versions, on the other. But I don’t have the experience to know if this is that much of an issue.

Do I need to include every single module, or only those I will ever use? Is dracut a more suitable option for generating a fallback generic UKI?

Regarding your second suggestion, I would still need to be able to use my system to install the matching kernel version and generate the UKI for it specifically.

Am I getting it right or am I misunderstanding anything? Have I overlooked any other potential compromises your suggestions might bring?

Again thank you for your both answers and help.

Edit: Clarification and additional questions

Last edited by Ch4n3 (2024-04-29 22:45:14)