Date: Sun, 8 Mar 2015 16:48:51 -0700 From: John-Mark Gurney <jmg@funkthat.com> To: Steven Hartland <killing@multiplay.co.uk> Cc: "Matthew D. Fuller" <fullermd@over-yonder.net>, freebsd-geom@freebsd.org Subject: Re: RFC: Pass TRIM through GELI Message-ID: <20150308234851.GA32329@funkthat.com> In-Reply-To: <54FCCFC3.4000007@multiplay.co.uk> References: <20150308000131.GP1742@over-yonder.net> <54FC4E99.4080202@multiplay.co.uk> <20150308223552.GR1742@over-yonder.net> <54FCCFC3.4000007@multiplay.co.uk>
next in thread | previous in thread | raw e-mail | index | archive | help
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."
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20150308234851.GA32329>