james hughes wrote:
On Dec 20, 2006, at 1:37 PM, Bill Sommerfeld wrote:
On Wed, 2006-12-20 at 03:21 -0800, james hughes wrote:
This would be mostly a "vanity erase" not really a serious "security
erase" since it will not over write the remnants of remapped sectors.
Yup. As usual, your milage will vary depending on your threat model.
My gut feel is that there's a cost-benefit sweet spot near a mechanism
which provides for the prompt overwrite of recently deallocated blocks
with either zeros or newly allocated data,
What happens when the machine crashes after the blocks are deallocated
but before they are scrubbed? Is that covered?
I would hope so, and I believe this would fall out from the all ways
consistent on disk transactional nature of ZFS.
with more intensive bleaching
reserved for when disks are taken out of service.
If I had a choice of destroying disks or running a program that will
take hours to complete (with dubious quality), I would (and do) choose
to destroy the disk.
Not all customers can make that same choice though. Some times you need
to give the broken disk back to the vendor as part of the replacement
otherwise you are buying a new disk.
We aren't talking about very high security environments here, and even
in those the NIST recommendations suggest you do something like this AND
physically destroy the disk.
This is more targeted at the financial, education and home user worlds
than military or other high sensitive environments.
It is all about using the appropriate tool given the risks you are
willing to take for a given cost of physical and time resources.
--
Darren J Moffat
_______________________________________________
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
