From owner-freebsd-hackers@FreeBSD.ORG Fri Jul 4 10:29:45 2014 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id BC89FAE1 for ; Fri, 4 Jul 2014 10:29:45 +0000 (UTC) Received: from mailout05.t-online.de (mailout05.t-online.de [194.25.134.82]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mailout00.t-online.de", Issuer "TeleSec ServerPass DE-1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 7C28C299F for ; Fri, 4 Jul 2014 10:29:44 +0000 (UTC) Received: from fwd35.aul.t-online.de (fwd35.aul.t-online.de [172.20.27.145]) by mailout05.t-online.de (Postfix) with SMTP id AE361215926 for ; Fri, 4 Jul 2014 12:29:35 +0200 (CEST) Received: from [192.168.119.33] (Thn40yZB8h2KXAd1s179-9cfjCkgE6kYdcAAD5nXXc8sp52qOs4BdyxMYi1Z2jrgcL@[84.154.115.126]) by fwd35.t-online.de with esmtp id 1X30kG-1KyMxU0; Fri, 4 Jul 2014 12:29:32 +0200 Message-ID: <53B68203.2030704@freebsd.org> Date: Fri, 04 Jul 2014 12:29:23 +0200 From: Stefan Esser User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: "hack >> \"freebsd-hackers@freebsd.org\"" Subject: Re: geli+trim support References: <7E2718485A3E405D89E5EAB331E9ED70@multiplay.co.uk> <53B6427D.1010403@gooch.io> In-Reply-To: <53B6427D.1010403@gooch.io> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-ID: Thn40yZB8h2KXAd1s179-9cfjCkgE6kYdcAAD5nXXc8sp52qOs4BdyxMYi1Z2jrgcL X-TOI-MSGID: c33743a3-1427-4157-822f-de3cfa7bee9c X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Jul 2014 10:29:45 -0000 Am 04.07.2014 07:58, schrieb Jesse Gooch: > IIRC, TRIM is bad for encryption anyway. You want everything to be > random noise, even the empty sectors. TRIM defeats this. Does it? The NAND blocks that are trimmed are put back on the internal free list of the device, and may still be accessible (at least with diagnostic commands). But their contents should have been encrypted and thus "look" like random noise. This is a problem of all flash devices, that you can only access through an flash adaptation layer. Even trying to overwrite the old data "in place" is likely to preserve the old blocks and to write to new blocks (due to wear-leveling). TRIM lets the device know, that the block should be considered empty (and reads will return dummy data), while "overwriting" with random will make a read return that data. You should not be able to access the old contents with regular read commands, in either case. And with diagnostic commands, you'll probably still be able to read the old (encrypted) content. But TRIM may lead to blocks being erased and reused earlier, than without TRIM. So, I do not think that TRIM is weakening file system encryption ... Regards, STefan