From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <mbroz@redhat.com>
Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28])
	by mail.saout.de (Postfix) with ESMTP
	for <dm-crypt@saout.de>; Fri, 23 Apr 2010 13:48:38 +0200 (CEST)
Message-ID: <4BD18899.7080700@redhat.com>
Date: Fri, 23 Apr 2010 13:46:33 +0200
From: Milan Broz <mbroz@redhat.com>
MIME-Version: 1.0
References: <20100422004842.5eb40c0a@gmail.com> <4BCF8371.60306@redhat.com>
	<20100422222227.GC15879@linux-m68k.org>
	<4BD15F13.3040604@redhat.com>
	<20100423111337.GA26121@linux-m68k.org>
In-Reply-To: <20100423111337.GA26121@linux-m68k.org>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Subject: Re: [dm-crypt] LUKS - SSD trim
List-Id: <dm-crypt.saout.de>
List-Unsubscribe: <http://www.saout.de/mailman/options/dm-crypt>,
	<mailto:dm-crypt-request@saout.de?subject=unsubscribe>
List-Archive: <http://www.saout.de/pipermail/dm-crypt>
List-Post: <mailto:dm-crypt@saout.de>
List-Help: <mailto:dm-crypt-request@saout.de?subject=help>
List-Subscribe: <http://www.saout.de/mailman/listinfo/dm-crypt>,
	<mailto:dm-crypt-request@saout.de?subject=subscribe>
To: Richard Zidlicky <rz@linux-m68k.org>
Cc: dm-crypt@saout.de, Felix Blanke <felixblanke@gmail.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