Re: [dm-crypt] LUKS - SSD trim

[Richard Zidlicky <rz@linux-m68k.org>]

On Fri, Apr 23, 2010 at 01:46:33PM +0200, Milan Broz wrote:

> If the default should be reject it - I am really not sure...
> 
> We have already this situation:
>  - zeroed disk (not randomised) and encryption.

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.

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

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