[Cryptography] WIPEONFORK in Linux 4.14

[Nico Williams]

On Sat, Nov 25, 2017 at 11:08:48AM -0500, Jerry Leichter wrote:
> > A lot it the time it isn't a disk, and even when it is can you trust
> > that the 'write zeros' did it over all data and metadata blocks?
> > Consider the case where your 'disk' is actually an iSCSI or FCoE LUN
> > backed by a copy on write raid storage system (such as ZFS). Then
> > that itself is backed by SSDs doing wear levelling and other
> > optimisations.
> 
> None of these technologies existed, even in labs, at the time the VMS
> feature was developed.  At the time, disks were disks and writes went
> to where you put them - with, granted, rare exceptions for bad blocks
> (though for at least some of the disks of that era, bad blocks were
> handled in the driver, not in device firmware).

Even back then there was bad block remapping.  Sure, there weren't going
to be a lot of bad blocks to remap, but still, it was an issue.

It's long been the case that absolutely ensuring secure deletion of a
file is difficult or impossible without destroying the device.

> Going back to the main point, though:  Making secure erasure *the
> responsibility of the file system* gives you the best chance of
> ensuring it will be done in whatever way the media involved support.

Or getting an error if it can't be done.

I agree with this.  Secure file deletion should be a proper system call,
ultimately implemented by the actual filesystem.  Until that happens, it
might as well not exist, and even then, getting it right is hard for all
the reasons given in this thread.

> User-level code - even aside from the problem that it's easy to forget
> to use it - is insulated by so many layers of abstraction that it's
> unlikely to continue to succeed as technologies evolve.  [...]

+1

> (Beyond that, you could well assert that secure erase should be the
> responsibility of the firmware, or whatever is close enough to the raw
> hardware to know what's *really* doing on.  Which is true - but of
> course puts that responsibility in code you have no access to and no
> way to audit.)

Ideally all SSDs should have a raw access mode, with no wear levelling,
so that one could use ZFS-like CoW filesystems that are SSD-aware and
can do wear levelling in software.  The less the firmware does, the
easier it is to test it and establish trust in it, even for a third
party.  The controllers on the SSDs should also be open to third party
firmwares.

Nico
--