From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail.cs.helsinki.fi (courier.cs.helsinki.fi [128.214.9.1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.saout.de (Postfix) with ESMTPS for ; Fri, 23 Apr 2010 12:20:39 +0200 (CEST) From: Mikko Rauhala In-Reply-To: <4BD15F13.3040604@redhat.com> References: <20100422004842.5eb40c0a@gmail.com> <4BCF8371.60306@redhat.com> <20100422222227.GC15879@linux-m68k.org> <4BD15F13.3040604@redhat.com> Content-Type: text/plain; charset="ISO-8859-1" Date: Fri, 23 Apr 2010 13:20:38 +0300 Message-ID: <1272018038.2669.40.camel@phantom.hip> Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Subject: Re: [dm-crypt] LUKS - SSD trim List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: dm-crypt@saout.de pe, 2010-04-23 kello 10:49 +0200, Milan Broz kirjoitti: > On 04/23/2010 12:22 AM, Richard Zidlicky wrote: > > isn't TRIM considered information leakage in the case of dm-crypt? It is leakage indeed, but for many purposes acceptable at least as such. I personally would want TRIM support on my dm-crypt-on-lvm SSD to improve lifetime and performance; I'm not too worried about leaking empty block information. (I would be somewhat interested though if someone knows of particular ways that empty block data could leak other information; known-plaintext attacks against filesystem data structures and through them against the encryption key springs to mind, but I recognize I'm just talking out of my ass here, grasping at worst-case straws.) I do think that dm-crypt, as a security solution, should probably offer optional dropping of TRIM commands when dm gains support for it; some uses may be more sensitive (and/or some users may wish to wear thicker tinfoil than myself). This is probably not critical, though: > 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. This would detract from the usefulness of dm-crypt, as you would be artificially limited in what you can run on top of it to meet your paranoia quota. However, considering in addition that many (most/all? - at least ext4, btrfs, gfs2) filesystems that make use of TRIM on Linux do appear on a quick glance to make this optional through the (no)discard mount options, it wouldn't indeed be a very bad thing for dm-crypt to Just Do It anyway. > dm-crypt is just transparent layer, it is configured some way and > configuration depends on your requirements and previous analysis. A "Drop TRIMs" flag could still be useful as just such a configuration option that you could set accordingly after said analysis, the ability to _often_ block TRIMs higher up on the stack notwithstanding. -- Mikko Rauhala - http://www.iki.fi/mjr/blog/ The Finnish Pirate Party - http://piraattipuolue.fi/ World Transhumanist Association - http://transhumanism.org/ Singularity Institute - http://singinst.org/