SSD encryption: TRIM possible/useful?

Natanji · 2011-03-11 15:46:15

Hello everyone,
since my current main system hard drive in my laptop is failing, I am looking for a replacement and this got me thinking about maybe using a SSD instead of a HDD, mainly to conserve power, but also to improve the fluidity of my system by the better access times.

However, I would never run a laptop without encryption since I don't want to risk my data getting into the wrong hands (e,g. in case I forget it somewhere or it gets stolen). Previously I have used cryptsetup to completely encrypt my Linux partitions (minus the boot partition, of course), then used an LVM to get different volumes inside the encrypted partition. I also have a data partition that uses Truecrypt.
I am fully aware that the speed improvements of an SSD will be a lot less than what it could be. I don't expect more than perhaps 90 MB/s sequential read/write speed *tops* since my CPU will be the limiting factor there. But that's okay: the HDD is merely half as fast as that, and I expect bigger improvements with non-sequential reads of many small files (Pacman, I'm looking right at you).

However, there is one point where I worry, and that is the TRIM command. I'm no expert on SSDs, but from what I understood this command is important for SSDs performance. So my question is: can I actually use TRIM *inside* the LVM volumes *inside* the encrypted partition? I would guess this is problematic due to the space not really being "free", but taken up by random/encrypted data. Also, I am wondering as to what the implications are: if this means that the SSD itself gets a little slower, I would probably not need to care much since my CPU is already a limiting factor anyways. I would care a lot however if this affects the life of the SSD dramatically. I'm especially curious if the wear-leveling mechanisms of the SSD are basically compromised by encryption, since from outside the SSD will always be completely full. Some posts on the net suggest leaving 10 percent of the SSD's capacity unpartitioned as a countermeasure. Do I need to do that? Is that enough?

stqn · 2011-03-12 05:08:35

I have never encrypted my disks (yet) but I did some research when I bought my SSD a few months ago.

IIRC, by that time TRIM was disabled for encrypted LVM partitions, I think because it is a security risk (it lets attackers know which sectors are unused.) Whether this is just disabled by default, or completely impossible to enable, I don't remember.

Different SSDs have very different algorithms. They also have different sizes of additional hidden capacity to help with wear-leveling. So I don't think your questions about the impact of TRIM and unpartitionned capacity can be answered easily, at least not without looking at a specific model of SSD.

Edit: Ok, I'll answer anyway . I am *not* a security expert, but I would assume that encryption is powerful enough for what little I have to conceal even with TRIM enabled.
I also left 10% of unpartitionned space on my SSD because I don't need all the space anyway (in fact I've got quite a bit of unused space on mine.) It might also be that a bigger unused space could make up for the lack of TRIM, so you could also try something like 20% unused space and TRIM disabled... But I'm just pulling this number out of my magic hat.

Last edited by stqn (2011-03-12 05:20:05)

Natanji · 2011-03-12 09:57:55

Yes, I am aware that SSDs using TRIM will not allow for plausible deniability. But this is fine with me, really.
Any idea where you heard that TRIM was disabled for encrypted LVM partitions? It would be really helpful to be able to read about that in some further detail.

Is there any way to find out how many actual "deleted" blocks are on a SSD? Or is that information hidden behind the SSD controller? I was thinking of getting a OCZ Vector 2 drive (Sandforce controller).

seiichiro0185 · 2011-03-12 14:20:57

I have a SSD in my laptop and the drive is fully encrypted (lvm on top of luks). I can (unfortunately) say that at least the kernel reports that discard (linux name for trim) is not supported for the ext4-partitions on the lvm.
There is a lvm/encryption enabled version of the wiper.sh script (does a "manual" trim getting all empty blocks and reporting them to the SSD) around which can be used instead.

If anyone has more specific info on this issue I would be interested too, since there isn't really any solid info anywhere to state what the current level of support for trim on lvm/luks is (at least I didn't find any).

ffjia · 2011-03-15 06:59:24

seiichiro0185 wrote:

I have a SSD in my laptop and the drive is fully encrypted (lvm on top of luks). I can (unfortunately) say that at least the kernel reports that discard (linux name for trim) is not supported for the ext4-partitions on the lvm.
There is a lvm/encryption enabled version of the wiper.sh script (does a "manual" trim getting all empty blocks and reporting them to the SSD) around which can be used instead.
If anyone has more specific info on this issue I would be interested too, since there isn't really any solid info anywhere to state what the current level of support for trim on lvm/luks is (at least I didn't find any).

What about other trim supported filesystem? Like brtfs?

seiichiro0185 · 2011-03-15 07:06:21

ffjia wrote:

seiichiro0185 wrote:
I have a SSD in my laptop and the drive is fully encrypted (lvm on top of luks). I can (unfortunately) say that at least the kernel reports that discard (linux name for trim) is not supported for the ext4-partitions on the lvm.
There is a lvm/encryption enabled version of the wiper.sh script (does a "manual" trim getting all empty blocks and reporting them to the SSD) around which can be used instead.
If anyone has more specific info on this issue I would be interested too, since there isn't really any solid info anywhere to state what the current level of support for trim on lvm/luks is (at least I didn't find any).
What about other trim supported filesystem? Like brtfs?

I didn't try other filesystems (I don't trust btrfs yet since it is still marked experimental). But since trim is working fine (at least kernel doesn't say otherwise) on my unencrypted/un-lvm'd boot-partition I think the issue is not with the filesystem but with the underlaying lvm/crypt layer

scorpyn · 2011-03-15 12:13:54

dm-crypt doesn't support trim (yet, but apparently it's a planned feature).

Doesn't seem like loop-aes supports trim either.

http://thread.gmane.org/gmane.linux.ker … crypt/4075
http://loop-aes.sourceforge.net/loop-AES.README

Natanji · 2011-03-22 16:26:13

I found a small script called "wiper.sh" for manually "trimming" a encrypted LVM logical volume: http://sourceforge.net/tracker/index.ph … tid=736684
Please note that the current version of this script (available in AUR in the "wiper" package) does NOT have trim support for encrypted LVM volumes. You need to follow the link and download the patched wiper script, which is sadly based on an older version of wiper.sh but at least works in my scenario.

One more thing should be noted here. On my laptop (Thinkpad X60 Tablet), dmcrypt seriously slows down the SSD. Random access time is down to 10% compared to no encryption, which is a lot. Speedtesting the SSD, I only get around 30-50 MB/s in sequential write access.To me, this shows that encryption can really be a major bottleneck for SSDs. Of course dmcrypt is also kind of outdated, either - I mean come on, it doesn't even use multithreading, and that in 2011. Shucks.

At least they seem to be aware of the problem and might be fixing it somewhen: https://bugzilla.kernel.org/show_bug.cgi?id=17892

lkraav · 2011-04-08 22:47:34

I just came across a post on some development mailing list that said you can get artificial multithreading by creating splitting your disk into multiple partitions and then joining them with LVM, then encrypting that volume. Every partition supposedly gets its own handler that way.

What I am trying to figure out is how much these massive performance drops can be fixed by just getting the low level software, such as dm-crypt up to date.

Last edited by lkraav (2011-04-08 22:48:39)

Fackamato · 2011-04-08 23:44:14

lkraav wrote:

I just came across a post on some development mailing list that said you can get artificial multithreading by creating splitting your disk into multiple partitions and then joining them with LVM, then encrypting that volume. Every partition supposedly gets its own handler that way.
What I am trying to figure out is how much these massive performance drops can be fixed by just getting the low level software, such as dm-crypt up to date.

I brought that up on LKML a while ago: http://lkml.org/lkml/2010/3/11/152

So yeah, several partitions on the device, each encrypted. Joins these devices with LVM (I suppose md would do as well) in a "RAID0" and you get what you want, I suppose.

I wonder if the device would seek itself to death. Less of a concern on a SSD though.

lkraav · 2011-04-09 08:03:36

very good thread, thanks. i am setting my i3 ulv laptop up with 60gb ssd so no aes-ni for me. i think i will:
* distribute 40gigs into 4 partitions
* encrypt them with dm-crypt
* join 2 with with btrfs for /root
* join 2 with with btrfs for /home
* leave 20 gigs for /pub random unencrypted storage, -o discard

i'm not fully able to picture how TRIM works, will work or doesn't work for this setup.
it will be fine on /pub.
but what will happen inside the crypted areas in dm-crypt's current state regarding also ssd built-in garbage collection?
should i mount my btrfs -o ssd or ssd_spread or nothing when sitting on top of dm-crypt?
how will the processes change when dm-crypt will get support for TRIM?
-o noatime,nodiratime,compress are still good idea probably (https://forums.gentoo.org/viewtopic-p-6 … ml#6347333)?

Last edited by lkraav (2011-04-12 13:21:19)

lkraav · 2011-04-09 11:06:21

what the hell forum software is this, page reload = repost without any notification? having no in-topic search made me *facepalm* already before as well.

litemotiv · 2011-04-09 11:24:21

lkraav wrote:

what the hell forum software is this, page reload = repost without any notification? having no in-topic search made me *facepalm* already before as well.

Ranting is not going to make things any better ikraav.

lkraav · 2011-04-09 11:29:45

litemotiv wrote:

lkraav wrote:
what the hell forum software is this, page reload = repost without any notification? having no in-topic search made me *facepalm* already before as well.
Ranting is not going to make things any better ikraav.

Thanks for fixing, can you move the issue "rant" into a support subforum?

almost done setting up, but most of the questions are still unanswered, updated the list a couple of posts up.

Last edited by lkraav (2011-04-10 16:41:06)

Arch Linux

#1 2011-03-11 15:46:15

SSD encryption: TRIM possible/useful?

#2 2011-03-12 05:08:35

Re: SSD encryption: TRIM possible/useful?

#3 2011-03-12 09:57:55

Re: SSD encryption: TRIM possible/useful?

#4 2011-03-12 14:20:57

Re: SSD encryption: TRIM possible/useful?

#5 2011-03-15 06:59:24

Re: SSD encryption: TRIM possible/useful?

#6 2011-03-15 07:06:21

Re: SSD encryption: TRIM possible/useful?

#7 2011-03-15 12:13:54

Re: SSD encryption: TRIM possible/useful?

#8 2011-03-22 16:26:13

Re: SSD encryption: TRIM possible/useful?

#9 2011-04-08 22:47:34

Re: SSD encryption: TRIM possible/useful?

#10 2011-04-08 23:44:14

Re: SSD encryption: TRIM possible/useful?

#11 2011-04-09 08:03:36

Re: SSD encryption: TRIM possible/useful?

#12 2011-04-09 11:06:21

Re: SSD encryption: TRIM possible/useful?

#13 2011-04-09 11:24:21

Re: SSD encryption: TRIM possible/useful?

#14 2011-04-09 11:29:45

Re: SSD encryption: TRIM possible/useful?

Board footer