Live data from Hacker News

Arch Linux Btrfs with hibernation in a swapfile

nwb.sh

41–45 of 45 posts

Re: Arch Linux Btrfs with hibernation in a swapfile

#41
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 ne…

Fascinating! How do you sign your kernel every time you recompile it? Do you need to store a new key into the UEFI every time?

Re: Arch Linux Btrfs with hibernation in a swapfile

#42
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 ne…

What's the point of auto-unlocking using the TPM? Does this mean people may be able to access your data without a password?

Re: Arch Linux Btrfs with hibernation in a swapfile

#43
post #37

Earlier quoted context omitted.

You don't set it aside, unused pages just get compressed to save space.

Okay, I think I don't know how swap works on Linux. Is it: When there's no more ram, swap is used or When ram hasn't been used in a while, it is sent to swap Or maybe a mix of both?

Both, yes.

The second one depends on your configuration, and your configuration depends on your hardware and your use-case. For example I have some 4GiB VPSs with a single vCPU and slow IO, so I configure the virtual memory to aggressively compress unused ram with lz4; decompressing them takes no CPU power and is orders higher throughput and lower latency than any disk swap can ever be, even when using just 1 vCPU. Then it means I have gigabytes of RAM that is used as file cache, instead of wasting that space with unused ram, and when everything is needed at the same time it just drops the cache. Having all that cache availability also means that it can take in a lot of files without locking up.

The first one also happens when you have too much RAM allocated for your things. When it's temporary until your applications finish it'll swap around and slowly finish eventually, but depending on your over-allocation and your swap's speed it can take significantly longer.

Re: Arch Linux Btrfs with hibernation in a swapfile

#44

Earlier quoted context omitted.

> 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 ne…

What's the point of auto-unlocking using the TPM? Does this mean people may be able to access your data without a password?

The point is that the PC boots up fully unattended. People could access my data without a password if they stole my machine and somehow managed to log in to it, say through a bug in the desktop manager on the login process. The LUKS key is in memory, so I guess if they can somehow read that, they could also access the drive. But I figure the convenience is worth it, I don't expect to be a high-level target for this. And if I were, the 5$ wrench attack would probably work better.

If they stole the hard drive, they wouldn't be able to access the data, the TPM wouldn't release the key.

Re: Arch Linux Btrfs with hibernation in a swapfile

#45

Earlier quoted context omitted.

> 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 ne…

Fascinating! How do you sign your kernel every time you recompile it? Do you need to store a new key into the UEFI every time?

I use sbupdate [0] to build the unified kernel image and to sign it with my keys. It's run by a hook in the arch's package manager whenever the kernel, the initrd or the firmware images change. I saw the other day that systemd recently got an utility to do this, but I've never looked into that. sbupdate has been working fine for me for several years now.

It doesn't store a new key in the uefi, it signs the new image with the key that uefi already knows about.

See [1] for the whole setup and [2] for the signing part specifically.

[0] https://github.com/andreyv/sbupdate

[1] https://wiki.archlinux.org/title/Unified_Extensible_Firmware...

[2] https://wiki.archlinux.org/title/Unified_Extensible_Firmware...

Post reply on HN