Arch Linux

Ovion

Member

Registered: 2013-02-24

Posts: 78

[solved] Best Practice for SSDs with crypto on it regarding TRIM

Hi,

I was doing some research on this matter but did not find too much information on that that's more useful than confusing.

The setup is the following: I have an SSD (Crucial, Marvell-Controller) with two partitions: a small one for /boot and a bigger one for the rest, which is a LUKS-Container. I left some unpartitioned space at the end of the SSD. I'd like to *not* enable TRIM on the LUKS-device for security purposes.

I was wondering now:

I read that TRIM does reduce the write amplification of garbage collection. But shouldn't the garbage collection do not write at all, but just erase cells with no information on it?

If TRIM helps keeping up performance: do I need to explicitly trim the unpartitioned space? Or does this area behave like the spare area?

If TRIM of the unpartitioned space is necessary: what's the most elegant way to do so?

If someone could shed a little light on this matter, that would help a lot and would be greatly appreciated.

Last edited by Ovion (2015-03-09 19:20:13)

dragonn

Member

Registered: 2012-05-04

Posts: 65

Re: [solved] Best Practice for SSDs with crypto on it regarding TRIM

You don't need to TRIM unpartitioned space, this is completed unlogic idea, read how TRIM works and  watch it does. Short answer - TRIM manages you data so the will be no free space between the data - means:

some_files1 --- free_space --- some_files2
affter trim:
some_files1 ---  some_files2  --- free_space

So your SSD don't need to search for free space across the disk when you save files.
And I don't thing TRIM will hurt  security in any way.

Last edited by dragonn (2015-03-09 16:45:09)

Ovion

Member

Registered: 2013-02-24

Posts: 78

Re: [solved] Best Practice for SSDs with crypto on it regarding TRIM

actually TRIM can indeed lead to information leakage.

Therefore in case one only has (except for the small /boot) one big crypto-container that does not pass TRIM, TRIM is actually not necessary as there is no file deletion from the disk's perspective, just a file modification (and therefore no need to reorder file blocks as they are never freed from the mapper's point of view, just altered), right?

dragonn

Member

Registered: 2012-05-04

Posts: 65

Re: [solved] Best Practice for SSDs with crypto on it regarding TRIM

Well ok, I don't know this , for me this is a little bit securitocholic but I understand that some one can really need this (I use only encfs for my important data ). Hmm but I think you are mostly right, if there will be no file deletion TRIM will be mostly not needed.

EDIT you can run TRIM manual too via fstrim and for example the fill the free space witch random data an then delete this file. In this way I think you can TRIM you SSD without avoiding security. Only the lifetime of the SSD will be hurt.

Last edited by dragonn (2015-03-09 16:54:05)

frostschutz

Member

Registered: 2013-11-15

Posts: 1,637

Re: [solved] Best Practice for SSDs with crypto on it regarding TRIM

I have the same setup. Crucial SSD, LUKS, TRIM (cron.weekly fstrim). A full hexdump (minus gigabytes of random data) looks like this: https://bpaste.net/raw/505157 (tell me about it)

There is no issue with security. At least, none I care about. So the attacker can see how much free space there is [and where]. The where part is important since lots of small files give a different picture [lots of small free spaces in between] than a single very large file would [no free space in between], assuming there is no fragmentation worth mentioning [which Linux filesystems are usually good at]. So an attacker could probably make some guesses about your amount of data and file sizes. On the other hand I don't see how that's important, in ecryptfs you get this kind of info for free, and I have all sorts of files in all sorts of sizes either way, so it's not a big secret.

The question is, when all it takes to crack your encryption setup is a keylogger or a $5 encryption wrench, does it really matter?

Don't use TRIM on your SSD if you don't want to (there are lots of reasons not to TRIM... like better data recovery chances if you delete something by accident). But don't fool yourself thinking it's somehow really important for your security...

As for unpartitioned space, if it ever was in use before, you need to trim it once. Create a partition on it, then blkdiscard the partition, then delete the partition. That way it's good until it's "in use" again because you dd all over it or had it resynced in a RAID.

Apart from that, TRIM does all the things you said (reduce write amplification, performance, etc. etc.) but it's not like the SSD can't take it if you're not writing 24/7 because it's a database server burning up or something.

Last edited by frostschutz (2015-03-09 19:19:16)

Ovion

Member

Registered: 2013-02-24

Posts: 78

Re: [solved] Best Practice for SSDs with crypto on it regarding TRIM

right, the impact of TRIM on the encryption is indeed not too big. But the interesting question is, would there be the necessarity for TRIM if one follows the advice in the linked blogpost? If I make the luks-Device hand through TRIM-commands, then it's all quite trivial at this point.

Regarding the unpartitioned space: makes absolute sense and is quite obvious thinking about it. Well, probably information overflow at the point of pasting.^^

Nevertheless, thanks for the input.

Edit:

There is no issue with security.

Well, if you can determine information within the LUKS-container (which can be the case as outlined in the linked blogpost), then there *is* actually an issue with security. One can decide that the issue is neglectable for the use case, but saying there is *no* issue might be a little underestimating the fact that there is information leakage.

Again: it probably doesn't really matter that someone knows that there is an ext4 in the container, because most devices out there will probably run with ext4, but the fact that the information that there is an ext4, XFS, whatever else in it is leaked is quite remarkable, I think.

Last edited by Ovion (2015-03-09 19:38:18)

ANOKNUSA

Member

Registered: 2010-10-22

Posts: 2,141

Re: [solved] Best Practice for SSDs with crypto on it regarding TRIM

Well, if you can determine information within the LUKS-container (which can be the case as outlined in the linked blogpost), then there *is* actually an issue with security.

Free tip: the purpose of using encryption on a personal or company computer is to foil burglars, muggers and identity thieves. Enabling TRIM won't hurt you in that regard. If you "need" a level of security that would (ostensibly) stop professional forensics experts, you're either excessively paranoid, or you probably did something awful, and your new enemies will find some other way to get what they want.

Last edited by ANOKNUSA (2015-03-09 20:32:53)

---

Linux != Windows  ::  Ask Questions the Smart Way  ::  Configs

Ovion

Member

Registered: 2013-02-24

Posts: 78

Re: [solved] Best Practice for SSDs with crypto on it regarding TRIM

Yes, I'm aware of that xkcd and as I said myself, the information leakage is probably neglectable.