Re: [dm-crypt] LUKS - SSD trim

[Milan Broz <mbroz@redhat.com>]

On 04/23/2010 01:13 PM, Richard Zidlicky wrote:
> On Fri, Apr 23, 2010 at 10:49:23AM +0200, Milan Broz wrote:

>> The same logic - should I ban old ciphers and weak IV because they are insecure?
>> Nope, it is not dm-crypt level decision.
> 
> 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?

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.

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

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