RFC: Pass TRIM through GELI

[John-Mark Gurney]

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."