TRIM support via dm-crypt/device-mapper

Question

Getting a new laptop with SSD tomorrow. I need to know about the current status of dm-crypt and TRIM. I have seen several conflicting reports and most activity around this question seems to be > 1 year old. Some say that dm-crypt TRIM passthrough has been included in multiple recent kernel versions (which is not a problem for me, since I use Arch). Some say that the support still does not exist. Can I get a clear, well-sourced answer on the status of dm-crypt TRIM support? git commits or mailing list announcements that mention this feature would be ideal.

The answer to this question has big potential to influence the way I architect my new laptop's disks. Hopefully it will be useful to some others to have a decent, up-to-date answer.

Solution 1

For the record, this functionality did NOT exist when I first posted this question. I asked on the mailing list and was informed by Milan Broz that discard passthrough for dm-crypt targets still had not been implemented. Milan indicated that he intended to implement this at some point, but did not state when.

After digging around in dm-crypt.c and related files for a while, it appeared that TRIM support would be fairly trivial to add. I wrote the list asking for their general advisement on the task before I jumped in. The next day, Milan submitted a patch that implements TRIM pass-through on dm-crypt and this has been staged into linux-next. It should be included in the Linux 3.1 kernel.

TRIM passthrough must be enabled explicitly. There are potential security issues in using TRIM on a dm-crypt'd device, because TRIM sends information about block usage to the firmware on the device which then marks recently freed areas as usable (as I understand it, anyway). This means that an interested party can derive information about patterns of disk usage. For instance, it was postulated that an attacker could almost definitely learn what filesystem was in use on the encrypted medium through this data. An attacker may also be able to learn more useful information, like that you had a lot of big files saved until recently (big contiguous TRIM'd blocks).

Please see these threads for reference:

http://www.redhat.com/archives/dm-devel/2011-June/msg00093.html

http://www.redhat.com/archives/dm-devel/2011-July/msg00042.html

http://www.redhat.com/archives/dm-devel/2011-July/msg00088.html

tl;dr: TRIM passthrough support for dm-crypt targets will exist in Linux >= 3.1 but must be enabled manually via cryptsetup and/or dmsetup due to data leakage that may allow profiling based on disk usage patterns.

Solution 2

As of kernel 3.2.x, dm-crypt + brtfs is supposed to be safe. See the reply to my question from Chris Mason:

http://permalink.gmane.org/gmane.comp.file-systems.btrfs/15554 and http://permalink.gmane.org/gmane.comp.file-systems.btrfs/15564

Comments

[jeffcook2150]

Thanks, but that answer is still non-definitive and over a year old. I would like a definitive, recent answer. I guess I will have to mail the list, just hoping SU would be a quick shortcut :p

[user1686]

Well, if it already worked a year ago...

[jeffcook2150]

"I guess it works because my SSD is not slow" is not really a reliable indicator of whether TRIM support is actually functional.

[user1686]

Which is exactly what I have never said.

[jeffcook2150]

That's what the post you've quoted says.

[jeffcook2150]

Thanks honig, I had found that before. Please see the answer I just added, it provides detail on real discard support for dm-crypt targets.

[Mitch McMabers]

Thanks for the explanation! Most of us don't care if the "attacker" can guess what filesystem we use (due to the data layout on disk) or can guess that we've deleted lots of big files (lots of trim zeroed space). Those worries may matter for some corporation. But for home users, SSD health matters more: USE TRIM. Without TRIM, the SSD (yes, even "garbage collection" ones) will have to shuffle around all that dead, unused data in the wrongful belief that it may be used later. That leads to lots of useless writes and earlier SSD death. It also reduces SSD write-performance over time.