Live data from Hacker News

Arch Linux Btrfs with hibernation in a swapfile

nwb.sh

11–20 of 45 posts

Re: Arch Linux Btrfs with hibernation in a swapfile

#11
post #7
post #4

Interesting! I went on a similar journey recently with debian and FDE on luks2, which involved a fair amount of learning and messing around, but I got there. No Btrfs though, just plain old ext4+swap volumes using lvm on luks2, and a small uefi partition. My /boot is encrypted so I enter the LUKS2 passcode before grub can even access its config, and I've rolled an unlock key into the initramfs (which is loaded by gru…

An alternative to MokManager/shim is to enroll your own key. You'll also need to convince your kernel package to create a UKI under /efi instead of regular initramfs under /boot, and to sign the UKI with your key. Eg on my OpenSUSE system, the kernel package runs dracut to build the initramfs in /boot, and it's three lines of config to co-opt dracut to build a UKI in /efi and sign it with my key instead. So installin…

> An alternative to MokManager/shim is to enroll your own key.

I was under the impression that that was exactly what I was doing with mokmanager/shim? dropping into a utility that would perform key enrolment?

Perhaps I have seriously misunderstood!

Re: Arch Linux Btrfs with hibernation in a swapfile

#12

Fwiw I no longer use disk swap files for anything, but ZRAM swap instead. It's mature, it's in the linux kernel, it's faster, and less wearing on SSDs, and RAM is cheap. I don't have a linux laptop though, so don't know how it affects hibernation. Anyone know how/if hibernation works on a laptop using ZRAM swap instead of disk-based swap?

RAM is pretty cheap but it's not free and not always possible to upgrade, and my personal computers keep ending up with gigabytes of data in memory that won't be touched for hours or ever. I'm happy spending a negligible amount of SSD lifetime to clear up that space.

Re: Arch Linux Btrfs with hibernation in a swapfile

#13
post #4

Interesting! I went on a similar journey recently with debian and FDE on luks2, which involved a fair amount of learning and messing around, but I got there. No Btrfs though, just plain old ext4+swap volumes using lvm on luks2, and a small uefi partition. My /boot is encrypted so I enter the LUKS2 passcode before grub can even access its config, and I've rolled an unlock key into the initramfs (which is loaded by gru…

What's the point of encrypting /boot exactly? From an Encrypt All The Things! perspective I get it, but practically... it seems overkill?

Re: Arch Linux Btrfs with hibernation in a swapfile

#14
post #4

Interesting! I went on a similar journey recently with debian and FDE on luks2, which involved a fair amount of learning and messing around, but I got there. No Btrfs though, just plain old ext4+swap volumes using lvm on luks2, and a small uefi partition. My /boot is encrypted so I enter the LUKS2 passcode before grub can even access its config, and I've rolled an unlock key into the initramfs (which is loaded by gru…

> Hibernate is less interesting, and apparently unsupported using secure boot anyway.

That's not the case. I have a similar setup to yours (/ on ext4 with separate swap, on LVM on LUKS, separate /efi) and my box hibernates just fine with secure boot and auto-unlock via TPM.

The difference with your setup is I don't use grub, but have the UEFI load a signed unified kernel image directly. Since this works so well, I never had a reason to mess around with yet another moving piece (grub or other bootloader).

As another commenter said, I haven't attempted to mess around with the MOK. I just replaced all the secure boot keys with my own, and I've also signed MS's Windows key (but not the 3rd party one) for my dual-boot needs.

---

For specifics: This is an up-to-date Arch Linux install, running on an HP EliteBook 840 G8 (11th gen intel). I know Debian may have older components than arch, but this setup has been working for more than a year now.

IIRC, the most significant change was brought by systemd 251 which started supporting auto-unlocking LUKS with the TPM. Before that, on an older computer with the same general setup, hibernation worked well, too. I just needed to input the unlock password (which I was too lazy to do, so I just used my yubikey - see https://github.com/agherzan/yubikey-full-disk-encryption).

Re: Arch Linux Btrfs with hibernation in a swapfile

#15
post #4

Interesting! I went on a similar journey recently with debian and FDE on luks2, which involved a fair amount of learning and messing around, but I got there. No Btrfs though, just plain old ext4+swap volumes using lvm on luks2, and a small uefi partition. My /boot is encrypted so I enter the LUKS2 passcode before grub can even access its config, and I've rolled an unlock key into the initramfs (which is loaded by gru…

What's the point of encrypting /boot exactly? From an Encrypt All The Things! perspective I get it, but practically... it seems overkill?

Presumably to avoid tampering of the kernel and initrd, since GP doesn't use secure boot.

Re: Arch Linux Btrfs with hibernation in a swapfile

#16
I just did this last week and ran into an issue with LUKS: https://lore.kernel.org/cryptsetup/CAD-Ua_hPjBLHK0cyEz3k7KYB...

LUKS wouldn't accept my password, no matter how simple it was.

Turns out a BIOS update somehow messed up RAM settings which caused memory errors. And as LUKS needs a lot of memory for some of it's description operations bit flips can cause all of that to fail.

That was frustrating!

Re: Arch Linux Btrfs with hibernation in a swapfile

#17
post #11
post #7

Earlier quoted context omitted.

An alternative to MokManager/shim is to enroll your own key. You'll also need to convince your kernel package to create a UKI under /efi instead of regular initramfs under /boot, and to sign the UKI with your key. Eg on my OpenSUSE system, the kernel package runs dracut to build the initramfs in /boot, and it's three lines of config to co-opt dracut to build a UKI in /efi and sign it with my key instead. So installin…

> An alternative to MokManager/shim is to enroll your own key. I was under the impression that that was exactly what I was doing with mokmanager/shim? dropping into a utility that would perform key enrolment? Perhaps I have seriously misunderstood!

I'd expect "MokManager" to... manage the MOK. Never used it, though. For one PC whose UEFI was recalcitrant, I've had to use another tool, called "KeyTool". It may or may not be the same thing, but mine let you change multiple kinds of keys, and, in particular, the platform key (aka the "root" key).

There are several steps. First, you usually have to put the UEFI in "custom mode", where you install your keys and end with the Platform Key. You typically get some kind of warning when enrolling the PK similar to "this will get the system out of custom mode".

I've found the Arch guide to be fairly clear: https://wiki.archlinux.org/title/Unified_Extensible_Firmware...

You should be able to adapt it to other systems.

Re: Arch Linux Btrfs with hibernation in a swapfile

#18
post #11

Earlier quoted context omitted.

> An alternative to MokManager/shim is to enroll your own key. I was under the impression that that was exactly what I was doing with mokmanager/shim? dropping into a utility that would perform key enrolment? Perhaps I have seriously misunderstood!

I'd expect "MokManager" to... manage the MOK. Never used it, though. For one PC whose UEFI was recalcitrant, I've had to use another tool, called "KeyTool". It may or may not be the same thing, but mine let you change multiple kinds of keys, and, in particular, the platform key (aka the "root" key). There are several steps. First, you usually have to put the UEFI in "custom mode", where you install your keys and end…

MOK is short for Machine Owner Key, which is just a way of saying "a key you enroll in your UEFI secure boot variables that is under your control".

Or that's what I thought anyway, if it's not actually doing that, and is just enrolling them in some sort of shim-internal DB, then it's a lot less interesting and I'll abandon that approach...

I don't necessarily want to change the 'root' PK ... or maybe I do if it's the only way to install a machine-owner trusted key in the real UEFI... I'll look at KeyTool in case it makes saving a key under my control to the db easier/actually work. Though the keytool I'm familiar with is a java pkcs#12 manipulation tool!

(on further reading, it looks like shim/mokutil creates a new key-set in nvram, separate to the UEFI stuff, that it manages itself and uses internally. This is not what I was trying to achieve and seems very much like vendor lock. I surely shouldn't need to use shim to boot if I'm signing stuff with my own keys... and it doesn't seem like it has even managed to persist this custom keyset. Back to the drawing board!).

Re: Arch Linux Btrfs with hibernation in a swapfile

#19
post #4

Interesting! I went on a similar journey recently with debian and FDE on luks2, which involved a fair amount of learning and messing around, but I got there. No Btrfs though, just plain old ext4+swap volumes using lvm on luks2, and a small uefi partition. My /boot is encrypted so I enter the LUKS2 passcode before grub can even access its config, and I've rolled an unlock key into the initramfs (which is loaded by gru…

What's the point of encrypting /boot exactly? From an Encrypt All The Things! perspective I get it, but practically... it seems overkill?

As the other poster mentioned, without secure boot, there are no guarantees about a kernel or initramfs that are sitting out there in plaintext (and yes, someone could mess with my grub install).

It was mostly because "this should be possible, right?"

So yeah - Encrypt all the things :)

Re: Arch Linux Btrfs with hibernation in a swapfile

#20

Fwiw I no longer use disk swap files for anything, but ZRAM swap instead. It's mature, it's in the linux kernel, it's faster, and less wearing on SSDs, and RAM is cheap. I don't have a linux laptop though, so don't know how it affects hibernation. Anyone know how/if hibernation works on a laptop using ZRAM swap instead of disk-based swap?

Seems silly to set aside ram to use when your ram runs out. What am I missing here?
Post reply on HN