Question about Full Disk Encryption wiki entry

[L1NTHALO]

Hey,

trying to encrypt my laptop with FDE and I'm currently following the wiki entry for FDE (https://wiki.gentoo.org/wiki/Full_Disk_ ... om_Scratch).
I'm confused by some parts:

1. I want to create a detached header on an USB drive with which to encrypt the disk. I've created that header but if I now create a key file for that disk, it says it isn't encrypted (/dev/nvme0n1p1 is not a valid LUKS device).
2. The wiki says to create all your headers, key files etc but then after that you should format your disks? What am I missing?
3. What do I need an Extended Boot Partition for? Is it only for MBR? Will putting the detached header, key files, initramfs and kernel image on the EFI drive work with grub?
4. Do I need GRUB or can you also do the whole process with EFISTUB?

Thank in advance!

[GDH-gentoo]

1. I want to create a detached header on an USB drive with which to encrypt the disk. I've created that header but if I now create a key file for that disk, it says it isn't encrypted (/dev/nvme0n1p1 is not a valid LUKS device).

Creating the key file comes first, it must exist before you create the LUKS container, because you need to tell cryptsetup luksFormat about it.

2. The wiki says to create all your headers, key files etc but then after that you should format your disks? What am I missing?

After you create the LUKS container, you must open it with cryptsetup open and create a filesystem. That's section 6 of the Wiki article.

3. What do I need an Extended Boot Partition for? Is it only for MBR? Will putting the detached header, key files, initramfs and kernel image on the EFI drive work with grub?

No, the Wiki article talks about an EFI System Partition (ESP), so it assumes a UEFI installation. The Extended Boot Partition is mounted at /boot and holds kernel, initramfs and GRUB stuff (including its configuration file). I suppose that the article chose that partition layout to make it easier to do the installation of GRUB, kernel and initramfs according to the Handbook.

Yes, all those could be in the ESP I believe.

4. Do I need GRUB or can you also do the whole process with EFISTUB?

You could in theory, but if you are using a separate initramfs, you rely heavily on the UEFI firmware's ability to correctly handle Boot#### variables and pass an initrd= kernel parameter to the EFI stub.

Otherwise, you have to embed the initramfs in the kernel, and that requires customizing the kernel's configuration, as shown in section 7.3 of that Wiki article.

[zen_desu]

Everything stated above is accurate and true. there are multiple partition schemes shown on the rootfs encryption page, I plan to do something similar with the FDE page. A /boot partition if you have an ESP is entirely optional. Some people prefer this because it means you can use fancier filesystem things (fancier than fat32 at least).

Concerning header files and key files, those could be stored on an ESP but it's worth noting that ESPs are generally easily readable.

[sMueggli]

What is your definition of FDE? Do you want to encrypt kernel and initramfs also?

[L1NTHALO]

Want to encrypt the whole drive and store the kernel and initramfs on a seperate unencrypted USB drive.

I've got it mostly working now but I'm not sure if I set it up correctly for a swap partition.

Currently I have an encrypted root partition and encrypted swap partition, both with seperate headers and one shared key file on the usb stick. Is that how you would do it?

[zen_desu]

Want to encrypt the whole drive and store the kernel and initramfs on a seperate unencrypted USB drive.

I've got it mostly working now but I'm not sure if I set it up correctly for a swap partition.

Currently I have an encrypted root partition and encrypted swap partition, both with seperate headers and one shared key file on the usb stick. Is that how you would do it?

I would not share a key file, you can have a separate one and possibly store it on the rootfs, where it's used later. If you use the dm-crypt service, it can setup a swap partition with a random key at every boot. This is nice if you don't plan to hibernate.

[L1NTHALO]

I do plan to hibernate so unfortunately that's not an option. How would your suggestion work? If I hibernate does both the rootfs and swap partition get encrypted and I decrypt rootfs and then swap?

[L1NTHALO]

Hey, since you're an ugRD dev, when doing make install I get an ugRD error that I miss the kernel module uas.
Not exactly sure what that module is, the nearest module I found was USB_UAS which I enabled.
Was planning on doing a new thread, but maybe you've got an idea?

[zen_desu]

I do plan to hibernate so unfortunately that's not an option. How would your suggestion work? If I hibernate does both the rootfs and swap partition get encrypted and I decrypt rootfs and then swap?

If you hibernate, you technically only need to decrypt the swap, and then that restores RAM and whatnot and the root is already mounted.

"resuming" is literally doing echo -n "/path/to/swap/dev" > /sys/power/resume
which restores the ram to the state it was in when you hibernated.

LVM is often used with encrypted swap so it can be under the same LUKS container as the root, and only one key needs to be used. There isn't too much wrong with sharing a key between the two, but I generally avoid reusing keys in any way if possible.

[zen_desu]

Hey, since you're an ugRD dev, when doing make install I get an ugRD error that I miss the kernel module uas.
Not exactly sure what that module is, the nearest module I found was USB_UAS which I enabled.
Was planning on doing a new thread, but maybe you've got an idea?

You could start a new thread, open an issue, ask in the discord, or ask in the irc. If you're running it directly, it reads kmods from the current running kernel version, sometimes this causes issues and another kernel version can be specified with --kver, you can read possible kernels from /usr/lib/modules

Checking on my system now, I have ugrd configured to look for the module named "uas", which corresponds to "CONFIG_USB_UAS", if you have it builtin, it won't be able to find the kmod so that's fine, but I would expect modinfo to say it's builtin when "uas" is queried. Ugrd more or less parses "modinfo -k <kver> modname", and builtin modules are generally put in modules.builtin.

It's also worth noting that ugrd doesn't currently support resuming from encrypted swap, there is a PR here which makes it possible.
https://github.com/desultory/ugrd/pull/139

I'm hesitating to add this and the person who made that PR has been testing it more thoroughly, but I'm paranoid about somehow accidentally writing to disks before resuming: https://www.kernel.org/doc/html/latest/ ... wsusp.html

[L1NTHALO]

Thanks! If I'd still like to use hibernate, would using dracut be more beneficial?
Also if only the swap gets encrypted during hibernate, can't you tamper with the unencrypted rootfs and either get the data from there or get the key for the encrypted swap?

[zen_desu]

Thanks! If I'd still like to use hibernate, would using dracut be more beneficial?
Also if only the swap gets encrypted during hibernate, can't you tamper with the unencrypted rootfs and either get the data from there or get the key for the encrypted swap?

I think dracut should currently support this, you're welcome to try that PR/truffle0's branch as well. The way it is implemented seems fine, but I'm not sure if it's worth taking extra measures to absolutely ensure nothing is written. AFAICT dracut and other systems do not take any extra measures, so I don't think it is as much of a risk as the kernel docs suggest.

fwiw the patches simply make it run the resume procedure a bit later, normally it would run after initial mounts, but this makes it run after luks/lvm actions. If you want to do this yourself, you can do a small edit to the init file in the initramfs. By default ugrd mounts everything 'ro' unless you take manual measures to make it 'rw', but im not sure if this is enough to ensure not a single bit is written, even to metadata portions, across any fs type.

If the root and swap use the same key, someone would need that key to meaningfully tamper with the data on either the swap or root. If they are somehow able to decrypt the swap, and the root has a different key, I think they may be able to derive the root key.

No matter how it's stored, if someone is able to properly modify your swap, they can make the system do whatever they want when it's resumed. A large part of why I have not added resume support to ugrd is it spooks me a bit so I do not use it. I've only added it and tested it as much as it's been requested.

[L1NTHALO]

Okay, thanks for the support!!

[Hu]

L1NTHALO, you seem to misunderstand how the encryption wrapping works. When using an encrypted drive, the drive is never decrypted in place. This would be slow and expensive. Instead, the data is encrypted before writing it to the drive. When you unlock the drive, you give the kernel the ability to decrypt the data into memory as it is read from the drive - but the data on the drive remains encrypted at all times. Therefore, when using hibernation with an encrypted rootfs and encrypted swap, your root remains encrypted whether the system is halted, active, or in hibernation. As zen_desu alluded to, the key to decrypt data from the rootfs is in memory while the rootfs is unlocked, and thus that key is written into the hibernation image. For that reason, if you use an encrypted rootfs, you should not hibernate to non-encrypted swap, since that would leave your valuable rootfs decryption key vulnerable in the unencrypted hibernation data. Instead, either do not hibernate at all or hibernate to an encrypted swap.

The kernel documentation contains strong warnings about not mounting rootfs during the resume kernel, before transferring control to the hibernated kernel. One common way of protecting against that mistake is to unlock swap and root separately, and to unlock root only after failing to resume from hibernation. This way, if the system was hibernated, the first thing the resume kernel does is unlock hibernation and transfer control. It cannot accidentally mount rootfs, because it does not yet have the rootfs decryption key.

[zen_desu]

Yes, hibernation has to be handled carefully if you have an encrypted root. That PR's implementation runs the resume before the root is mounted, immediately after the LUKS volume is opened and LVM groups are activated. This should just be enough to enumerate the UUID and resume, without affecting data, but it doesn't prevent the rootfs from being altered within the initramfs if a recovery shell is opened.

If you have a single LUKS partition with the root under a LVM volume, and the swap as a separate one, this should work.

It's also possible to use a swap file, unlock the root volume, then resume from that file offset.

[L1NTHALO]

Ok, that makes a lot more sense. However I'm still confused on how you set this up in practice.

Right now I have 2 partitions on my nvme: root and swap. I'm gonna encrypt both of them and I'll have /dev/mapper/root and /dev/mapper/swap.
I'm gonna store the detached header of rootfs on my USB drive, the header of swap on the rootfs.
The rootfs key file will be stored on my usb, the swap key file on the rootfs.

I'll have my kernel, initramfs etc on my USB drive so I need it to boot. In practice I'm gonna start my laptop with the USB drive.
When resuming from hibernation, I'm gonna decrypt rootfs with the key file on the USB drive to get to the swap header and key file, and then decrypt swap?

Is it gonna work like that and if it does how does the decryption process look? Say I'm booting from the kernel on my usb stick, do I get a tty to type the luksOpen command?

Maybe I'm way in over my head. An easier alternative would be to just encrypt my "important" partitions such as /home right?

[Hu]

Right now I have 2 partitions on my nvme: root and swap. I'm gonna encrypt both of them and I'll have /dev/mapper/root and /dev/mapper/swap.
I'm gonna store the detached header of rootfs on my USB drive, the header of swap on the rootfs.
The rootfs key file will be stored on my usb, the swap key file on the rootfs.

I'll have my kernel, initramfs etc on my USB drive so I need it to boot. In practice I'm gonna start my laptop with the USB drive.

You seem fine up through here.

When resuming from hibernation, I'm gonna decrypt rootfs with the key file on the USB drive to get to the swap header and key file, and then decrypt swap?

No, you risk corrupting your root filesystem if you try that. If the root filesystem was mounted when the system entered hibernate, then you must do one of two things at next power-on:

• Resume from hibernate without mounting the root filesystem, or even attempting to replay its journal.
• Wipe out the hibernation image, and boot clean as if the system had crashed instead of hibernated.

There is no guaranteed safe path that involves mounting the root filesystem in order to extract a swap key from it. You need the swap key before you can resume. Therefore, you cannot both store the swap key in the root filesystem and use that key to resume from hibernation. Your choices are to store the swap key somewhere else, or not to use resume.

Is it gonna work like that and if it does how does the decryption process look? Say I'm booting from the kernel on my usb stick, do I get a tty to type the luksOpen command?

That depends on how the initramfs chooses to prompt you for the password. Booting to a terminal is fairly common.

Maybe I'm way in over my head. An easier alternative would be to just encrypt my "important" partitions such as /home right?

You could choose that, but then you need to think carefully about where important content can go. If you have an unencrypted swap, your applications might spill sensitive data into swap. The same concern applies if /tmp is a disk-backed filesystem outside the encrypted container.

[zen_desu]

I think it is easiest to use LVM under LUKS so a single key can be used to decrypt everything, and the swap can be resume from without mounting the root.

If you're storing keys on the USB you could also store both keys there, but it would be simplest to use something like LVM so one key can be used. This also means only a single header file must be used.

There's nothing wrong with using 2 LUKS partitions, but it does reveal that you have 2 distinct encrypted partitions, if you have LVM under LUKS, that is not apparent by reading the partition table.

[L1NTHALO]

Thanks for the LVM tip! Never used it before but it really is a god send!! I have everything set up now with LVM under LUKS and everything is working except for one (hopefully tiny) detail.

I've used dracut for the initrd generation and got my kernel_cmdline set up correctly.

My problem is that I've got /dev/nvme0n1p1, which is my LUKS partition and connected with the detached header. After luksOpen I've got /dev/mapper/root, which is my LVM PV and under /dev/mapper/root I've got my LVM vg and lv's (root, swap, home).
Until now I've thought that I needed to supply /dev/mapper/root UUID to rd.luks.uuid but that makes no sense of course. I only did that because my /dev/nvme0n1p1 got no UUID but only a PARTUUID. I saw no way to supply a PARTUUID to the rd.luks.uuid. I don't get why nvme0n1p1 got no PARTUUID because it is a partition not a drive.
Am I screwed or is there any way to generate a UUID/repartition correctly?

(drives, partition layout, kernel post)
https://imgur.com/a/CclYNI9

Also after I've done this, I plan to update the wiki entry to make it a bit easier to follow. I had to use the arch wiki extensively for dracut + LVM + detached headers. Should I edit the main wiki entry directly or create on of these user guides?

[L1NTHALO]

I realized I probably forgot to give it a filesystem. Can I make a filesystem on it, without deleting everything else?

[Hu]

Please provide the partition layout and such as text, not as an imgur post. Currently, imgur fails to render due to a JavaScript error, so I cannot review your setup.

I do not know why you do not have a PARTUUID on nvme0n1p1. What is the output of blkid?

You would create a filesystem on an LVM LV. That should be possible without rebuilding any of the outer layers.

[zen_desu]

Also after I've done this, I plan to update the wiki entry to make it a bit easier to follow. I had to use the arch wiki extensively for dracut + LVM + detached headers. Should I edit the main wiki entry directly or create on of these user guides?

To avoid overcomplicating things, the current FDE/rootfs guides don't use LVM. The guides focus on the LUKS portions, such formatting, detaching the header, opening, etc.

If you wanted to make a subpage that explains LVM in context of LUKS, that could help.

How you specify the "root" doesn't differ too much if you add LVM as this should target the actual root filesystem, not containers like LVM or LUKS.

I think dracut should mostly autoconfigure LVM stuff, especially if you set hostonly.
ugrd autoconfigs lvm under luks, you'd only need to specify the header location.

[L1NTHALO]

Yeah, sorry I typo'd. The partition has no UUID but only a PARTUUID, presumably because of the detached header.
It is working now, however I didn't manage to make it happen with dracut. I've tried every single combination and tried letting dracut auto generate a cmdline all to no avail.
It seems to be a problem with dracut (viewtopic-t-1166504-highlight-fstab.html) because there's no way to enter your LUKS partition with a PARTUUID. You only have a PARTUUID with a detached header though because you lose the UUID (https://wiki.gentoo.org/wiki/Full_Disk_ ... _headers_2).
With ugRD it worked without problems.
There's a way to mod Dracut but using ugRD seems to be the easier alternative.

Huge thanks for the help guys!! I'll try to contribute back and add some wiki entries when I've got the time.