From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-bw0-f219.google.com (mail-bw0-f219.google.com [209.85.218.219]) by mail.saout.de (Postfix) with ESMTP for ; Fri, 23 Apr 2010 13:10:57 +0200 (CEST) Received: by bwz19 with SMTP id 19so20530bwz.1 for ; Fri, 23 Apr 2010 04:10:57 -0700 (PDT) Sender: Richard Zidlicky Date: Fri, 23 Apr 2010 13:13:37 +0200 From: Richard Zidlicky Message-ID: <20100423111337.GA26121@linux-m68k.org> References: <20100422004842.5eb40c0a@gmail.com> <4BCF8371.60306@redhat.com> <20100422222227.GC15879@linux-m68k.org> <4BD15F13.3040604@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4BD15F13.3040604@redhat.com> Subject: Re: [dm-crypt] LUKS - SSD trim List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Milan Broz Cc: dm-crypt@saout.de, Felix Blanke On Fri, Apr 23, 2010 at 10:49:23AM +0200, Milan Broz wrote: > On 04/23/2010 12:22 AM, Richard Zidlicky wrote: > > isn't TRIM considered information leakage in the case of dm-crypt? > > What do you mean? Information that some blocks are not used in device? yes. > 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. Layering problem. Traditionally dm-crypt was expected to provide fs agnostic transparent encryption. TRIM is something that breaks the layering assumption. > 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? I am not against having the possibility to pass through ata trim but it is debatable whether this should be the default behaviour. Richard