RFC: Pass TRIM through GELI

Pawel Jakub Dawidek pjd at FreeBSD.org
Mon Jul 13 15:30:25 UTC 2015


On Sat, Jul 11, 2015 at 02:15:53PM +0100, RW via freebsd-geom wrote:
> On Fri, 10 Jul 2015 17:28:37 -0500
> Matthew D. Fuller wrote:
> 
> 
> > 2) Security.  For whatever your threat model is, leaking the "how much
> >    space is in use" datum is unacceptable. 
> 
> It's not about how much space is free, it's about giving away which
> blocks do and don't contain data.
> 
> Perhaps more importantly TRIM breaks plausible deniabily, which was
> the the point of allowing the geli metadata to be store separately. You
> can't argue that a partition has been wiped with 'dd if=/dev/random ...'
> if the the partition has been subsequently trimmed.

Yes, you are right. I even suggest in man page to overwrite providers
with random data before using them. So what do you guys think about
implementing trim support this way:

	geli -d <trim|overwrite|ignore>

'overwrite' may be implemented later and 'trim' would be the default?

This option bascially defines how BIO_DELETE should be handled.

-- 
Pawel Jakub Dawidek                       http://www.wheelsystems.com
FreeBSD committer                         http://www.FreeBSD.org
Am I Evil? Yes, I Am!                     http://mobter.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.freebsd.org/pipermail/freebsd-geom/attachments/20150713/64052175/attachment.bin>


More information about the freebsd-geom mailing list