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