LWN: Comments on "Managing encrypted filesystems with dirlock"

Block-device encryption without reinstallation - luksipc

tajyrink — Sat, 04 Oct 2025 12:46:48 +0000

I have used luksipc multiple times and it has worked fine. https://github.com/johndoe31415/luksipc/

Block-device encryption without reinstallation

berto — Wed, 01 Oct 2025 20:43:47 +0000

You're right, and they don't actually had to change the device mapper, they do everything in userspace remapping the device on the fly.

Bcachefs

GhePeU — Wed, 01 Oct 2025 15:25:12 +0000

As far as I know bcachefs doesn't implement the fscrypt API and only supports whole filesystem encryption, analogous to LUKS, so it doesn't provide the features Valve needed.

Also as far as I know, nobody's working on fscrypt support for Btrfs anymore, after years of back-and-forth with the fscrypt maintainer the last news of the project was an email by Josef Bacik saying that Meta didn't need the feature anymore so it had been de-prioritized but he'd try to fix up what had been done and submit it... but that was in April 2024 and he left Meta and stepped back from kernel development since.

Block-device encryption without reinstallation

muase — Wed, 01 Oct 2025 15:20:12 +0000

I'm not familiar with the internals of the device mapper but I can imagine that this would need changes in dm-crypt: you would need to have a device that is only encrypted up to a certain offset, and that offset would change in real time while the device is being used.

As far as I know, there is cryptsetup-reencrypt, which already has an online-mode for reencryption but it seems that this also supports initial encryption. I'm not sure if you can use it to online-encrypt the currently booted volume; but if I understand the manpage correctly, it should be possible to boot into a minimal environment, start the encryption, convert everything to device-mapper volumes, and then reboot and continue the encryption online.

Block-device encryption without reinstallation

berto — Tue, 30 Sep 2025 22:34:58 +0000

Indeed, with detached headers it should be possible.

I'm not familiar with the internals of the device mapper but I can imagine that this would need changes in dm-crypt: you would need to have a device that is only encrypted up to a certain offset, and that offset would change in real time while the device is being used.

Block-device encryption without reinstallation

muase — Tue, 30 Sep 2025 21:30:20 +0000

Something like that would definitely be possible; BitLocker (Windows) and FileVault (macOS) have been offering similar functionality for years now; speaking from a technical pov, it's a solved problem.

Going further down that road: As LUKS2 supports detached headers, you could even do interesting shenanigans like simply storing luks-<partuuid>.bin in the boot or EFI partitions itself, and simply add another JSON key dmcrypt-progress to the header file. As AES-XTS is zero-size overhead, now you wouldn't even need to touch and shrink the existing partitions/filesystems anymore and could transparently encrypt block by block.

Does dirlock use the user PIN as part of the key derivation?

berto — Tue, 30 Sep 2025 21:23:29 +0000

Hi, dirlock doesn't currently use the PIN as part of the key derivation (when using the TPM), but that's a very easy thing to change. I'll evaluate that, thanks!

Block-device encryption without reinstallation

berto — Tue, 30 Sep 2025 21:13:18 +0000

I believe that BitLocker does something like that, it would certainly be a nice feature to have.

But I'm not sure how that would work in practice: the LUKS header alone takes several MBs, so apart from shrinking the filesystem you would have to either move all the data or put the superblock and the first few MBs at the end of the partition, and then use the device mapper to make those appear at the beginning.

ecryptfs?

berto — Tue, 30 Sep 2025 21:05:51 +0000

ecryptfs is unfortunately unmaintained: https://lore.kernel.org/lkml/20230403134432.46726-1-frank...

ecryptfs?

jcpunk — Tue, 30 Sep 2025 20:23:20 +0000

I'll confess I'm curious how this compares to ecryptfs.

Block-device encryption without reinstallation

geert — Tue, 30 Sep 2025 12:08:39 +0000

I think it would be possible to convert from an unencrypted to an encrypted block-device without reinstallation, by teaching dm-crypt to handle partially-encrypted block devices. The conversion procedure would be:
1. Unmount file system,
2. Shrink/modify file system to cater for space for the LUKS header and dm-crypt,
3. Add a LUKS header, and a counter that is initialized at zero (nothing encrypted yet),
4. Setup dm-crypt and remount file system,
5. Dm-crypt background task encrypts blocks, and updates the stored counter accordingly, until everything is encrypted.

Does dirlock use the user PIN as part of the key derivation?

DemiMarie — Tue, 30 Sep 2025 03:08:59 +0000

Or does it rely entirely on the TPM? The latter is a mistake due to vulnerabilities like faulTPM.

Same choice as Android

riking — Tue, 30 Sep 2025 00:14:28 +0000

The kernel fscrypt API is also how Android protects home directories. Seems like a solid choice.

Bcachefs

Cyberax — Mon, 29 Sep 2025 21:40:57 +0000

You still need to manage encryption keys, that's why dirlock is needed in any case.

Bcachefs

mmechri — Mon, 29 Sep 2025 20:58:33 +0000

I _think_ Bcachefs supports encryption, including enabling encryption on an already existing file system. I wonder if Valve considered that route, especially since (IIRC) they did fund a little bit of the Bcachefs development (or perhaps I remember this completely wrong. The details elude me right now)

ZFS

cen — Mon, 29 Sep 2025 19:26:29 +0000

ZFS with encrypted datasets could also solve most of the problems described in the article but I guess that would be a bridge too far for SteamOS. No in-place "turn on" feature too afaik.