Re: [dm-crypt] LUKS - SSD trim

[Milan Broz <mbroz@redhat.com>]

On 04/23/2010 10:09 PM, Richard Zidlicky wrote:
> On Fri, Apr 23, 2010 at 01:46:33PM +0200, Milan Broz wrote:

> 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. 

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.

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

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