Hacker News Reader

Comment by ylyn | Hacker News Reader

Swapfiles are quite common when you use FDE (say, LUKS) and you don't want your swap to be in plaintext on disk.

(Although, you could just have an entire LUKS-encrypted swap volume instead of a swapfile...)

While maybe not the most performant my favorite is LVM2 on top of a single large LUKS-encrypted partition (+no boot partition and a single (custom platform key) signed EFI bootable kernel blob containing the initram fs in the EFI partition).

This:

- Allows a encrypted swap partition (on in lvm2 on top of luks, sure not perfect but I don't really use swap)

- Allows hibernation (which I don't really use tbh.)

- Fully encrypted disc

- Fast boot (compared to e.g. encrypted grub, at least last time I checked)

- Easy resizing of partitions on demand

- Which in turn makes it easier to use more partitions (for /, /home, etc.), which is necessary for taking advantage of certain mount flags like noexec for security.

Anyway I think the reason Ubuntu uses a swap file is because it means you don't need to resize a partition when "upgrading" your RAM or similar (for hibernation to work). Through tbh. they should make the choice in the installer dependent of the hardware.

You still need an unencrypted EFI partition given what you describe, and the signed unified kernel image lives there, which means that you do in fact have a boot partition. My /boot mount is my EFI partition.

However, an alternative is having your EFI partition reside on a USB drive that in turn boots into your encrypted partition.

/boot is not the same as the efi system partition (ESP), sure you need to copy the signed kernel blob into the ESP but I still wouldn't recommend mounting ESP as /boot if your linux distro allows it.

The reason for this are many fold including that Linux assumes /boot is managed by it but the ESP isn't managed by Linux and might contain other EFI compatible programs. Another reason is that you want to make sure only the signed blob is in the ESP and nothing else, but depending on your distro and packages all kind of thinks might be put into /boot. Another reason is the dir structure. /boot is flat but ESP isn't meant to be flat e.g. in my case it's /EFI/<osname>/<efifiles>

E.g. my /boot partition contains "initramfs-linux.img", "intel-ucode.img" and "vmlinuz-linux" but my /esp contains only linux-signed.efi which packs the necessary image files, linux kernel, kernel parameters, boot splash screen etc.

Still what you can do (with reasonable effort) depends a bit on the Linux Distro you run.

Also in many default setups you have a /boot parition and a ESP partition, in your case you just folded both into one. In my case I don't have a boot parition and could as far as I know tweak my system not not have a /boot folder at all as it's not really used, it's just not worth the effort to do so.

My apologies and thanks for the clarification. I suppose I could see how you'd want to create a hook to create the unified image, in which case /boot or whatever could simply be a directory that holds the non-unified images.

I guess the point I was trying to make, is whether you call the partition that holds your unified kernel images /boot or /esp or whatever.. it is still a separate unencrypted partition that most people would associate with a boot partition, whether it is mounted at /boot or /esp.

Would the bug Linus is describing still bite you if your swap is in a separate LVM partition? (That's how Ubuntu 20.04 sets things up by default.)

Only if it's a swap file on a filesystem on that LVM partition, and even then if the filesystem is otherwise empty then there's no other data to accidentally overwrite, you might just trash the filesystem structure.

Then, if I'm understanding this correctly, the default setup in Ubuntu (at least in Ubuntu 20.04, which I happen to have installed on a couple of laptops recently), which has been mentioned both in this discussion and in the lwn.net article discussion, should be safe from the bug, since that setup, if you enable full-disk encryption, sets up two LVM partitions, one for root (called "vgubuntu-root") and one for swap (called "vgubuntu-swap"). They show up as separate LVM partitions in fdisk. The swap appears to me to just directly use the "vgubuntu-swap" partition.

Sounds fine. It would be strange if vgubuntu-swap contained an actual filesystem with a single file on it (the swap file).

This is my setup as well.

Even with full-disk encryption you have two options that I'd recommend over a swap file:

- lvm on luks: inside the luks dm-crypt container, create multiple logical volumes: one for swap, one for the root filesystem

- swap on dm-crypt: create a separate encrypted partition for swap

Since the swap data needs no permanence, it's possible to generate a new encryption key every boot. Debian's crypttab supports this out of the box [0]:

    cswap  /dev/sda6  /dev/urandom  cipher=aes-xts-plain64,size=256,hash=sha1,swap

(although I'd recommend using a /dev/disk/by-id/ path there, for obvious reasons. The scripts do check there's no valid signature on the partition before formatting, but still...)

[0] https://manpages.debian.org/buster/cryptsetup-run/crypttab.5...

> Since the swap data needs no permanence

Unless you want to hibernate!

In the most recent Debian installer, if you want to do FDE, it does:

partition > LUKS > LVM > swap volume

That way you get encrypted swap without having swap be a file in your filesystem.

most people I know who are paranoid to really go into the details of a FDE linux desktop/workstation environment choose to have no swap file, and at minimum 64GB of RAM. even safer if the swap doesn't exist.

Reply on news.ycombinator.com