Trim, SSD, and Encryption--Any point to urandom first?

cb474 · 2012-04-11 09:11:48

If I am setting up an encrypted system, on a SSD, with Trim enabled, is there any point to writing random data to the drive first (with urandom) as one would normally do?

My understanding is that Trim will write zeroes to unused portions of the drive anyway, to keep track of what space is available for optimizing writes to the drive (for wear leveling, etc.). So if in the long run, what the drive will look like is random information, where data is present, and zeros where there is no data. Then why not just zero out the drive to begin with, rather than using urandom?

In fact, would zeroing the drive to start help Trim from the beginning do what it's supposed to do?

Thanks for any thoughts.

graysky · 2012-04-11 11:07:11

Who normally writes from /dev/urandom to a new disk? /dev/zero is fine for the purpose of identifying bad blocks. I don't think trim writes zeros to free space either.

rwd · 2012-04-11 18:27:50

I believe point of filling a disk with random data is that it makes it harder for an attacker who gets hold of your disk to determine which parts are encrypted containers, and thus harder to decrypt it. I don't know if there is a way to use trim and still keep this feature, (nor much about encryption in general).

Last edited by rwd (2012-04-11 18:31:37)

cb474 · 2012-04-12 00:40:40

Yes, the point of overwriting the entire disk with random data, before setting up an encrypted system, is so that it is not possible to see where there is data and where there is just empty space on an encrypted drive. This is recommended by every encryption setup guide I have ever seen, including the Arch Wiki.

I'm not sure where I created the impression that I was asking a question about identifying bad blocks. I didn't mention them in my post and I don't know what it has to do with setting up an encrypted system (on an SSD with the Trim feature), which is the topic of my question.

The issue is, although it is normal to first overwrite the entire disk with random data, for an encrypted system, if you enable the Trim feature on an SSD it will write zeros to free space (as files are deleted, I believe). This helps the SSD do wear leveling and (I think) operate faster, issues exclusive to SSDs as opposed to regular magnetic hard drives. So once you enable the Trim feature, you will, at least (I think) in the long run, defeat the benefit of having written random data to the entire drive when the system was set up.

A lengthy explanation can be found here, for anyone interested: www.asalor.blogspot.com/2011/08/trim-dm-crypt-problems.html

My question is, will writing random data not only defeat the security/encryption benefits, but also make it hard for the SSD to operate the Trim function effectively? Will the SSD see all the random data as used space and not perform effective wear leveling? In which case, is it better to just zero out the drive first and then create the encrypted system, so that the SSD can use Trim properly?

Thanks to anyone who knows about how Trim with SSDs works and how random data could effect it.

Last edited by cb474 (2012-04-12 00:44:29)

graysky · 2012-04-12 09:04:41

I stand corrected.

/dev/zero · 2012-04-12 09:10:50

Is it possible to have two LUKS layers, say L and U for lower and upper, and only have TRIM apply to U? The zeros written in U would be encrypted and still appear random when viewed from L.

Or would this defeat the purpose of using TRIM? Or am I even missing something about the way TRIM works, which would make the whole idea just plain impossible?

cb474 · 2012-04-12 19:29:23

/dev/zero wrote:

Is it possible to have two LUKS layers, say L and U for lower and upper, and only have TRIM apply to U? The zeros written in U would be encrypted and still appear random when viewed from L.
Or would this defeat the purpose of using TRIM? Or am I even missing something about the way TRIM works, which would make the whole idea just plain impossible?

I'm not sure I know enough about it either, to evaluate this idea. I don't really even understand the distinction between upper and lower that you're making. My sense is that this would not work, because Trim is a function carried out by the the SSD controller, so it needs to "see" zeros from the outside (same point of view as a pontential attacker?). So I think it would still just see the encrypted data if I did this. But I could be totally misunderstanding what you're suggesting. I have not seen anyone suggest such a scheme, in guides about SSDs and enryption.

I have wondered if there is a way to have the kernel carry out a Trim like function, in lieu of the SSD controller. I know there are manual ways you can do it, I think, with hdparm. In fact, it's not entirely clear to me if the "discard" function of ext4, which enables trim, is a software based function or merely the way that the signal is sent to the SSD controller to use Trim.

There is also an issue of wear leveling, which I now believe (on further reading) may be a separate function of the SSD controller, from Trim. It might also benefit, as mentioned above, from having empty space filled with zeros or leaving a small unpartitioned part of the drive (I've read elsewhere) to be used by the controller for wear leveling. I'm also wondering if I need to do one of these things for the wear leveling to work.

Last edited by cb474 (2012-04-12 19:31:40)

/dev/zero · 2012-04-12 20:19:41

cb474 wrote:

I don't really even understand the distinction between upper and lower that you're making. My sense is that this would not work, because Trim is a function carried out by the the SSD controller, so it needs to "see" zeros from the outside (same point of view as a pontential attacker?). So I think it would still just see the encrypted data if I did this. But I could be totally misunderstanding what you're suggesting.

Maybe a nesting analogy rather than a layering analogy would have helped get the point across better. Consider this:

dd if=/dev/urandom of=/dev/sda1
cryptsetup luksFormat /dev/sda1
cryptsetup luksOpen /dev/sda1 L
cryptsetup luksFormat /dev/mapper/L
cryptsetup luksOpen /dev/mapper/L U

Now, any zero bits written in the U layer will be encrypted and look just as random as everything else once U is closed.

For example,

dd if=/dev/zero of=/dev/mapper/U
dd if=/dev/mapper/U     # Will show U contains zeros.
cryptsetup luksClose /dev/mapper/U
dd if=/dev/mapper/L     # Should show L contains random garbage, not zeros.

cb474 · 2012-04-12 23:21:22

I think I get the idea now. I didn't mean to suggest your explanation didn't make sense. Just that it perhaps exceeded my knowledge of Linux.

It still seems to me that that this wouldn't work, since Trim is a hardware function carried out by the SSD controller. I don't think the SSD reads even the basic files system, let alone logical devices in device mapper. My understanding is that when a file is deleted, if "discard" is enabled in ext4, it sends a signal to the SSD control indicating which blocks of data are no longer in use. So the SSD is only looking at the block level.

To this end, it will only be the first step, "dd if=/dev/urandom of=/dev/sda1," that matters. This will determine that the controller sees a drive full of random data. It will never look at what's going on in a logical volume. But when it gets the signal from the ext4 file system (or the kernel, wherever it comes from) the SSD controller will note that certain blocks are now unused and write zeros to them.

So the only way for the SSD to see zeros in the empty space, to begin with, would be to write zeros to /dev/sda1 or to the whole device (/dev/sda).

That's my understanding, could be wrong.

All that said, I'm really more concerned about getting Trim and wear leveling to work with encryption, than about having the most secure set up (where you can't tell what parts of the drive contain files and what parts don't).

R00KIE · 2012-04-13 15:32:36

@/dev/zero
I think you are getting the trim idea incorrectly. When you do a trim you just tell the ssd which sectors are free (not write zeros), the ssd will then erase the free cells so they can be written again when needed. By having 2 layers of encryption you might get the same effect as having trim disabled so no gain there (I really don't know, no experience with encryption).

As for wear leveling I suppose the ssd might still try to do some wear leveling even with trim disabled, however it will do writes considerably slower (check any recent ssd review and see the benchmark results).

/dev/zero · 2012-04-14 05:33:41

@OP

This just got posted to the dm-crypt mailing list. You may wish to track that thread.

cb474 · 2012-04-14 06:57:26

Thanks /dev/zero. I'll keep track of that. I've been learning way more about SSDs in the last couple days than I ever thought I would. It's funny the when it comes to encryption they are just not comparable devices to magnetic hard disks, with all sorts of unexpected complications.

I think my main question now is, if I fill the ssd with /dev/urandom first, am I going to completely hose the peformance of the drive? I'm leaning towards just doing a secure-erase with hdparm and leaving it at that.

R00KIE · 2012-04-14 11:31:50

cb474 wrote:

I think my main question now is, if I fill the ssd with /dev/urandom first, am I going to completely hose the peformance of the drive?

Most probably yes, the write performance will suffer, but should still be faster or comparable to the speed of a disk with moving parts.

cb474 · 2012-04-14 20:14:22

Thanks Rookie. The second question I have is will it seriously impact the how long the drive will last (because of the issue with SSDs having a limited number of times they can be written to)?

R00KIE · 2012-04-15 01:19:06

That I do not know. I guess that depends if the firmware has good wear leveling algorithms, but as ssds are still sort of in their infancy it may be a hit or miss thing. To aggravate that you have to take into account that the manufacturer will probably assume that the ssd will be used with an OS that supports trim and that trim will be used.

Another option you might have is hardware level encryption, where the disk itself takes care of encrypting and decrypting the data. I don't know if any ssd does this, and how secure it is (backdoors, firmware bugs, ....).

cb474 · 2012-04-16 01:00:18

One thing I don't understand is, does filling up the drive with random data undermine the ability of wear leveling to work correctly? Does the controller perceive the drive as full and not have space to use for wear leveling? Or is there always extra user inaccessible space for the controller to carry out wear leveling?

The drive I have does not carry out hardware level encryption. There are some new drives that do this, like the Intel 320 series, I think. But my understanding is that they work based on ATA passwords, or something like that, and do not keep the password very secure. So I've read some people saying that hardware level encryption is not very good on these devices.

R00KIE · 2012-04-16 15:00:17

If I'm not wrong all drives carry a certain amount of reserved flash space (that the user cannot see or access) that is used (at least) for reallocating bad flash cells. I wouldn't be surprised if some of that reserved space was used to help with wear leveling a full drive.

I guess you probably will have to research a bit more on that and try to find a forum more dedicated to flash based disks where these and other things may be explained/discussed.

cb474 · 2012-04-17 00:53:34

It does seem like what you're saying is correct (about reserved flash space). I have been researching around a lot about SSDs and encryption, but seem to have reached the limits of what I can find out there that addresses all of the complexities of SSDs. wearleveling, TRIM, and encryption. There seem to be very few people that actually understand all the technicalities and they don't always respond to one's posts the way one would hope Anyway, thanks for your thoughts.

Arch Linux

#1 2012-04-11 09:11:48

Trim, SSD, and Encryption--Any point to urandom first?

#2 2012-04-11 11:07:11

Re: Trim, SSD, and Encryption--Any point to urandom first?

#3 2012-04-11 18:27:50

Re: Trim, SSD, and Encryption--Any point to urandom first?

#4 2012-04-12 00:40:40

Re: Trim, SSD, and Encryption--Any point to urandom first?

#5 2012-04-12 09:04:41

Re: Trim, SSD, and Encryption--Any point to urandom first?

#6 2012-04-12 09:10:50

Re: Trim, SSD, and Encryption--Any point to urandom first?

#7 2012-04-12 19:29:23

Re: Trim, SSD, and Encryption--Any point to urandom first?

#8 2012-04-12 20:19:41

Re: Trim, SSD, and Encryption--Any point to urandom first?

#9 2012-04-12 23:21:22

Re: Trim, SSD, and Encryption--Any point to urandom first?

#10 2012-04-13 15:32:36

Re: Trim, SSD, and Encryption--Any point to urandom first?

#11 2012-04-14 05:33:41

Re: Trim, SSD, and Encryption--Any point to urandom first?

#12 2012-04-14 06:57:26

Re: Trim, SSD, and Encryption--Any point to urandom first?

#13 2012-04-14 11:31:50

Re: Trim, SSD, and Encryption--Any point to urandom first?

#14 2012-04-14 20:14:22

Re: Trim, SSD, and Encryption--Any point to urandom first?

#15 2012-04-15 01:19:06

Re: Trim, SSD, and Encryption--Any point to urandom first?

#16 2012-04-16 01:00:18

Re: Trim, SSD, and Encryption--Any point to urandom first?

#17 2012-04-16 15:00:17

Re: Trim, SSD, and Encryption--Any point to urandom first?

#18 2012-04-17 00:53:34

Re: Trim, SSD, and Encryption--Any point to urandom first?

Board footer