From owner-freebsd-geom@FreeBSD.ORG Sun Mar 8 23:48:59 2015 Return-Path: Delivered-To: freebsd-geom@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 2C9A9AFA for ; Sun, 8 Mar 2015 23:48:59 +0000 (UTC) Received: from gold.funkthat.com (gate2.funkthat.com [208.87.223.18]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "gold.funkthat.com", Issuer "gold.funkthat.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 048D092C for ; Sun, 8 Mar 2015 23:48:58 +0000 (UTC) Received: from gold.funkthat.com (localhost [127.0.0.1]) by gold.funkthat.com (8.14.5/8.14.5) with ESMTP id t28Nmp7k088376 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 8 Mar 2015 16:48:51 -0700 (PDT) (envelope-from jmg@gold.funkthat.com) Received: (from jmg@localhost) by gold.funkthat.com (8.14.5/8.14.5/Submit) id t28NmpiH088375; Sun, 8 Mar 2015 16:48:51 -0700 (PDT) (envelope-from jmg) Date: Sun, 8 Mar 2015 16:48:51 -0700 From: John-Mark Gurney To: Steven Hartland Subject: Re: RFC: Pass TRIM through GELI Message-ID: <20150308234851.GA32329@funkthat.com> References: <20150308000131.GP1742@over-yonder.net> <54FC4E99.4080202@multiplay.co.uk> <20150308223552.GR1742@over-yonder.net> <54FCCFC3.4000007@multiplay.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <54FCCFC3.4000007@multiplay.co.uk> X-Operating-System: FreeBSD 9.1-PRERELEASE amd64 X-PGP-Fingerprint: 54BA 873B 6515 3F10 9E88 9322 9CB1 8F74 6D3F A396 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ X-Resume: http://resnet.uoregon.edu/~gurney_j/resume.html X-TipJar: bitcoin:13Qmb6AeTgQecazTWph4XasEsP7nGRbAPE X-to-the-FBI-CIA-and-NSA: HI! HOW YA DOIN? can i haz chizburger? User-Agent: Mutt/1.5.21 (2010-09-15) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (gold.funkthat.com [127.0.0.1]); Sun, 08 Mar 2015 16:48:52 -0700 (PDT) Cc: "Matthew D. Fuller" , freebsd-geom@freebsd.org X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Mar 2015 23:48:59 -0000 Steven Hartland wrote this message on Sun, Mar 08, 2015 at 22:40 +0000: > > > On 08/03/2015 22:35, Matthew D. Fuller wrote: > > On Sun, Mar 08, 2015 at 01:28:57PM +0000 I heard the voice of > > Steven Hartland, and lo! it spake thus: > >> I don't see where your checking if the underlying device supports DELETE? > > From my understanding (which is hardly authoritative, to be sure, so > > I'm open to correction), I don't have to. GELI itself doesn't > > originate any BIO_DELETE's, so they're only coming from stuff on top > > of us. We just pass those through to what's underneath us and it does > > all the answering. If that doesn't support it, it would return an "I > > don't do that" response, which the filesystem (or whatever) on top of > > us handles[0] its way. So for _DELETE, as for _FLUSH and _GETATTR, > > GELI is just transparent. > > > > Am I mistaken? > > > Underlying BIO_DELETE support is optional, typically only supported by > SSD's via TRIM or UNMAP, so unless you check to see if the device > supports it you'll be translating delete so a noop, actually you'll be > forcing an extra layer to process the delete when it will never be able > to to. Considering that the upper layer will learn if it's supported or not, this is a minor issue... If an upper layer continues to issue _DELETE's after an EOPNOTSUPP error, then that's a different issue, and needs to be fixed there... > Given GEIL is all about security translating the delete to a noop > results in a pretty serious security issue I would say as it will leave > data which he user intended to be removed present on the device. Considering that you have to to enable it on your provider, I don't see a security issue... The patch documents this behavior... I don't see a "major" security issue w/ passing through _DELETE... Yes, on some devices, the data may be around for longer, but it is benifical on SSDs... If we wanted to be paranoid, we could write data before doing a _DELETE, but on SSDs that's just pointless... Provide the tools to the admin and document properly... I would say that the man page wording isn't complete... Maybe adding: Even after a sector has been deleted, it is possible that the data may still be readable depending upon how the underlying provider implements .Dv BIO_DELETE . BIO_DELETE should be used w/ .Dv. The date is not bumped... Even though it will be incorrect, it's useful to include to remind people that it needs to be done... -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not."