[Cryptography] WIPEONFORK in Linux 4.14

[Jerry Leichter]

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

I have no idea what's happened to the feature in the intervening years.  Storage hardware today is, indeed, very hard to erase - to the extent that Apple dropped support for "secure erase" of disks in recent versions of its MacOS Disk Utility since it no longer ships any disks, just SSD's, and there's generally no way to securely erase them.

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.  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.  Granted, for some media, the only alternative may be file-specific encryption (which reduces, but doesn't eliminate, the problem:  You still need to ensure that when you erase the key, it's *really* gone).

(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.)
                                                        -- Jerry