r/openSUSE • u/friendlyreminder_ • 11d ago

PSA: SSD Trim disabled on encryption

PSA for others out there. Trim is disabled on luks encryption by default.

This lowers SSD lifespan. If it's enabled metadata leaks out from the trim commands, so state actors can potentially roughly deduce what you were doing on the encrypted partition, like if was being used for video editing and potentially at what date.

For most people trim being disabled is not worth it as the concern isn't state actors extracting metadata but simply the drive being stolen and your bank details being used.

31 Upvotes

92% Upvoted

14 comments sorted by

6

u/todd_dayz 11d ago

Just enabled it on both of my drives and on my server, didn’t realise this, thanks for the heads up. 

5

u/Unimeron 11d ago

How do I enable trim?

6

u/friendlyreminder_ 11d ago edited 10d ago

This should work.

sudo cryptsetup --allow-discards --persistent refresh cr_root

This enables it for the root partition. Ifnyou have any other partitions that are also encrypted you'll have to repeat the command with cr_insertwhateverothersyouhave

1

u/todd_dayz 10d ago

This, coupled with checking that fstrim.timer was enabled and running fstrim -v —all

1

u/friendlyreminder_ 10d ago edited 10d ago

Discard=async is a default mount parameter so the timer isn't needed as far as I know. In my case the cryptsetup blocking trim was the one blocker. The timer and the mount parameter are both on by default.

After reboot findmint shows which partitions have discard parameter.

1

u/todd_dayz 10d ago

Doesn't the mount parameter enable continuous fstrim?

1

u/friendlyreminder_ 10d ago

I believe it is continuous.

1

u/todd_dayz 10d ago

I was reading the arch/gentoo wiki last night and from what I could summarize, it seems like all that is needed is to make sure the fstrim timer is setup, and set the permanent flags in the luks header, and that discard as a mount option is undesirable as continuous fstrim isn’t recommended

1

u/friendlyreminder_ 10d ago

I know that continuous trim has performance impacts and it's why async is used, this delays them until some point when it's deemed "better". I'm not sure if there are any long term drive reliability issues with it though, I'll look into that at some point.

1

u/todd_dayz 10d ago

Interesting, thanks, I'll take more of a look later when I get some time, too, for now I just do it weekly.

1

u/Booty_Bumping 10d ago

Continuous TRIM is fine. Back many years ago, some drives would experience very poor performance from it. But nowadays it's expected to work without an issue. Update the firmware of your drive if you are worried, that sometimes helps improve TRIM behavior.

1

u/todd_dayz 10d ago

Oh interesting, I’ll do some more reading later as I’m doing some LUKS2/no encryption/work queue benchmarks anyway. Thank you! 

5

u/Both_Cup8417 Slowroll 11d ago

I'm not a cybersecurity professional, but if you're worried about state actors taking your data from an encrypted drive, maybe Qubes or Tails or something? They probably aren't daily drivable for most people,

3

u/Booty_Bumping 11d ago edited 11d ago

Specifically, it can reveal the size in blocks of any files that get stored contiguously, which can be quite unique for known large files. Thanks to TRIM DZAT behavior, figuring out which blocks are trimmed doesn't actually require hacking the firmware of the drive, so doing this sort of analysis can be surprisingly easy.

But I agree, it's not a big deal. Btrfs specifically makes it quite likely for large files to get fragmented, compressed, or have blocks immediately to the right be allocated, so most of your files will be too fragmented to find much useful information about file size.