LUKS - SSD trim

Hi,

does anybody know a way to trim a luks encrypted SSD? (btrfs filesystem on top, but I think that doesn't count)

Regards,
Felix B.

TRIM is not yet supported in device-mapper devices (thus dm-crypt/LUKS too) but it is planned.

Milan

Thanks for your reply.

Do you have any idea how long will it takes? My ssd is quiet slow without trim :/

Regards,
Felix

Am Thu, 22 Apr 2010 01:00:01 +0200
schrieb Milan Broz <[email protected]>:

You can image it to a file on a conventional disk and image it back, e.g. wioth dd_rescue. That should also fix things, at least for a while.

Arno

Arno Wagner, Dr. sc. techn., Dipl. Inform., CISSP -- Email: [email protected] 
GnuPG:  ID: 1E25338F  FP: 0C30 5782 9D93 F785 E79C  0296 797F 6B50 1E25 338F
----
Cuddly UI's are the manifestation of wishful thinking. -- Dylan Evans

If it's in the news, don't worry about it.  The very definition of 
"news" is "something that hardly ever happens." -- Bruce Schneier 

That's not possible because of a limitation in the underlying devicemapper.

Btrfs is specially suited for use with SSD, as a hint you could start with what I have in fstab in the mount section: "nobarrier,ssd_spread".

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

I guess it might help to check that your partitions are aligned to the erase blocks on the SSD, before you restore the image of your brtfs. Look here http://www.saout.de/pipermail/dm-crypt/2010-February/000584.html

Cheers,
Mark
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkvQDAEACgkQ3b8v4BN9hRRSrgCfWeLBY437QMYCSXHPQ0m89GQd MMQAn2kqFW6IFcEgQ3Ebo3kMmt4p/i9G
=gQav
-----END PGP SIGNATURE-----

FYI: upstream svn have already automatic alignment code (requires kernel 2.6.33 and above - topology ioclt calls supported).

I need just test it that it uses proper offset claculation:-), but should be in cryptsetup 1.1.1

Anyway, yes - for SSD is VERY important to align the whole device stack (partition, LUKS, LVM2, ...).
More important than TRIM support.

Milan

Hi,

first of all thank you guys a lot for helping me!

I hope it is ok if I write one more question about those things:

I aligned the partition (which was allready fine) and the luks part to the same value.

scooter ~ # fdisk -l /dev/sdb

Disk /dev/sdb: 160.0 GB, 160041885696 bytes
224 heads, 56 sectors/track, 24918 cylinders
Units = cylinders of 12544 * 512 = 6422528 bytes
Disk identifier: 0x5328d0af

   Device Boot      Start         End      Blocks   Id  System
/dev/sdb1   *           1          34      213220   83  Linux
/dev/sdb2              35         704     4202240   82  Linux swap /
   Solaris /dev/sdb3             705       13244    78650880   83  Linux
/dev/sdb4           13245       24918    73219328   83  Linux

scooter ~ # cryptsetup luksDump /dev/sdb4
...
Payload offset: 12544
...

The filesystem on top is btrfs. I didn't find any information about the align thing and btrfs. I dont know mutch about align and those stuff :/

The problem is:

scooter ~ # hdparm -tT /dev/sdb3

/dev/sdb3:
Timing cached reads: 18686 MB in 2.00 seconds = 9354.32 MB/sec
Timing buffered disk reads: 758 MB in 3.00 seconds = 252.61 MB/sec

scooter ~ # hdparm -tT /dev/mapper/ssd

/dev/mapper/ssd:
Timing cached reads: 17432 MB in 2.00 seconds = 8725.18 MB/sec
Timing buffered disk reads: 158 MB in 3.02 seconds = 52.36 MB/sec

The first value is perfect, then second one really sucks. Obv. /dev/mapper/ssd is the decrypted /dev/sdb3

Any idea about that?

Regards,
Felix

Am Thu, 22 Apr 2010 09:42:41 +0100
schrieb mark <[email protected]>:

dm-crypt is slow - and when it is read I don't think alignment will do any difference. loop-AES might be faster.

Richard

isn't TRIM considered information leakage in the case of dm-crypt?

Richard

What do you mean? Information that some blocks are not used in device?

It depends what are you trying to do.

If it is problem, you should not use FS with TRIM support in the first place. dm-crypt basically should support TRIM if the request comes, it is just block device.

dm-crypt is just transparent layer, it is configured some way and configuration depends on your requirements and previous analysis.

The same logic - should I ban old ciphers and weak IV because they are insecure? Nope, it is not dm-crypt level decision.

Milan

pe, 2010-04-23 kello 10:49 +0200, Milan Broz kirjoitti:

It is leakage indeed, but for many purposes acceptable at least as such.

I personally would want TRIM support on my dm-crypt-on-lvm SSD to improve lifetime and performance; I'm not too worried about leaking empty block information. (I would be somewhat interested though if someone knows of particular ways that empty block data could leak other information; known-plaintext attacks against filesystem data structures and through them against the encryption key springs to mind, but I recognize I'm just talking out of my ass here, grasping at worst-case straws.)

I do think that dm-crypt, as a security solution, should probably offer optional dropping of TRIM commands when dm gains support for it; some uses may be more sensitive (and/or some users may wish to wear thicker tinfoil than myself). This is probably not critical, though:

This would detract from the usefulness of dm-crypt, as you would be artificially limited in what you can run on top of it to meet your paranoia quota. However, considering in addition that many (most/all? - at least ext4, btrfs, gfs2) filesystems that make use of TRIM on Linux do appear on a quick glance to make this optional through the (no)discard mount options, it wouldn't indeed be a very bad thing for dm-crypt to Just Do It anyway.

A "Drop TRIMs" flag could still be useful as just such a configuration option that you could set accordingly after said analysis, the ability to _often_ block TRIMs higher up on the stack notwithstanding.

Mikko Rauhala <[email protected]>       - http://www.iki.fi/mjr/blog/  
The Finnish Pirate Party         - http://piraattipuolue.fi/  
World Transhumanist Association  - http://transhumanism.org/  
Singularity Institute            - http://singinst.org/  

yes.

Layering problem. Traditionally dm-crypt was expected to provide fs agnostic transparent encryption. TRIM is something that breaks the layering assumption.

these are useful only in case someone has such an obsolete volume. But you would not seriously consider implementing new known weak features just on the ground that the user can choose some workaround?

I am not against having the possibility to pass through ata trim but it is debatable whether this should be the default behaviour.

Richard

That's why there are safe defaults in cryptsetup (userspace).
I just said that dm-crypt should be able to process it - where it should be configurable is another question.

Currently core device-mapper doesn't support TRIM at all. There must be per dm target implementation - so we can selectively disable that anyway.

So yes, kernel module option and/or optional mapping table parameter can be added. Well, no problem, already two requests for that:-)

If the default should be reject it - I am really not sure...

We have already this situation:
- zeroed disk (not randomised) and encryption.
You easily see which blocks were written and which are unused.
- almost the same if you can snapshot underlying device in time (ciphertext only). It is not new problem IMHO. TRIM makes it only worse.

Milan

people are known to initialise disks manually. But true, it would be cool if it could be added as a no-brainer (optional) for those who don't.

there is a huge immediate difference for some people: deniability (assuming the user was smart enough not to use a previously zeroed disk).

As of cryptographic attacks: I have no idea how easy it is to retrieve the TRIM data and how it is stored internally. But in the worst (and not quite unlikely) case the device would have something like a log-structured trim record which - if extracted by some means would reveal not only the free block count but would allow to infer things like file sizes of almost all files and lots of the filesystem structure and history.
It is impossible to overestimate the worst case information leak in this scenario.

So even in case the disk was not cleverly filled by garbage it could still make a huge difference in some cases.

Richard

I asked how TRIM (and SCSI discard) is handled and it seems that most of drives zeroes trimmed blocks (or the function is internal to drive - so undefined, we must expect the worst case).

So it is clear that an attacker can recognize which block was trimmed (reading zeroed blocks instead of "random" data). If there is some internal drive data related to TRIM available, it can be even worse.

So the option to disable TRIM requests in dm-crypt layer seems to be quite useful option to avoid these possible leaks.

yes.
Still probably most of people can ignore it (even leaking of file & disk sizes is not problem), but according to above, you are right it should default to safe operation.

(I used a quite stupid example to demonstrate the problem - take several SSD empty disks, use encryption and then format it with FS which TRIMs free space. Use one disk to store backup. Without TRIM you cannot say which disk contains data, with TRIM you can scan disk and see used block statistics - so you know which disk you should watch or install hacked fw etc:-)

Milan

it can be even much worse. The most evil case is a specially crafted device manufactured by a mighty agency which will record every single read/write/trim command. A few weeks ago it was on the news here that most copiers have builtin hard discs and make copies of what people are copying.. so who knows what is in our ordinary hard discs today.

The second most evil - and very realistic scenario is that any drive can have a log storing trim states/operations. If its an SSD device that log could be *very* huge if we are unlucky. Although I am not an expert on this devices I would think it is the obvious way to do it. All the information about trimmed blocks must be stored somewhere and in order to keep the "wear" low its likely to be log-structured, not a simple bitmask. There is not an official way to retrieve this backlog but there may be device specific undocumented proprietary ways to do it or someone might open the chip.

But there sure is no way to guarantee that any information that is ever entrusted to a blackbox device might not resurface again.

Richard

Only as temporary storage. Better copiers do a secure erase after the copy as well, but not all do. It is something copiers used for secret material can get certified for.

That is way you use encryoption on top. However, it is higly unlikely current HDDs/SSDs store a lot of information of this type. The storage space is just not there.

Arno

Arno Wagner, Dr. sc. techn., Dipl. Inform., CISSP -- Email: [email protected] 
GnuPG:  ID: 1E25338F  FP: 0C30 5782 9D93 F785 E79C  0296 797F 6B50 1E25 338F
----
Cuddly UI's are the manifestation of wishful thinking. -- Dylan Evans

If it's in the news, don't worry about it.  The very definition of 
"news" is "something that hardly ever happens." -- Bruce Schneier 

very offtopic, I would think there is certainly pressure from various agencies and companies not to erase anything. Given that printers are programmed to print secret identification patterns on every page there could be quite a few surprises lurking in copiers.

most will do clever traffic analysis trying to predict access patterns at the very least. Most likely not store everything to survive reboots but there can be exceptions.

Richard

On Sat, Apr 24, 2010 at 06:44:52PM +0200, Richard Zidlicky wrote:
[...]

Only for color printers. It serves to identify a printer that was used in couterfiting currency. Storing everything in copiers is infeasible. Thstorage available is just about enough for the largest possible print-job, usually not more than 1000 or so different pages. Given that this limit is routinely exceeded in a day, almost all pages will not be stored.

Sorry, but I openend my SSD. There are just no bits in there for this. My 30GB SSD has 2GB extra storage, most used for spares for broken cells. The rest cannot store a lot. In addition, the SSD does not have a clock that would be essential for adding timestamps to a data access pattern log.

Here is a story from my country some years back. The federal prolice wanted to have all emails copied and archived. The ISPs responded with the query where the cubic-meter of DAT tapes per day should go? After this (and after realizing the cost, which the police would have had to pay), the proposal was off the table.

Arno Wagner, Dr. sc. techn., Dipl. Inform., CISSP -- Email: [email protected] 
GnuPG:  ID: 1E25338F  FP: 0C30 5782 9D93 F785 E79C  0296 797F 6B50 1E25 338F
----
Cuddly UI's are the manifestation of wishful thinking. -- Dylan Evans

If it's in the news, don't worry about it.  The very definition of 
"news" is "something that hardly ever happens." -- Bruce Schneier 

hi,

you can try the modified version of the wiper.sh script (originally by mark lord but the new patches have not been commented by him so take care and do what the poster says => backup :)) for trimming a dmcrypt partition.
i just tested it and so far i found no problems or changes in comparison to my backup regarding trim.

https://sourceforge.net/tracker/index.php?func=detail&aid=2997551&group_id=136732&atid=736684

--------
one question regarding alignment whether the following is correct. i used the latest tools which should do this automatically:
fdisk (util-linux-ng 2.17.2) + cryptsetup 1.1.1-rc2, created with some 2.6.33.x kernel (don't know for sure anymore, i'm now running 2.6.33.4).

# fdisk -luc /dev/sda

Disk /dev/sda: 100.0 GB, 100030242816 bytes
255 heads, 63 sectors/track, 12161 cylinders, total 195371568 sectors Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0xe2d5b28c

   Device Boot      Start         End      Blocks   Id  System
/dev/sda1            2048      145407       71680   83  Linux
/dev/sda2          145408     4339711     2097152   82  Linux swap
/dev/sda3         4339712   195371567    95515928    5  Extended
/dev/sda5         4341760    98713599    47185920   83  Linux
/dev/sda6        98715648   193087487    47185920   83  Linux

/dev/sda5 e.g. is a cryptsetup/luks partition:

# cryptsetup luksDump /dev/sda5 | grep Payload
Payload offset: 4040

JG