deprovision: Implement device sanitization

[fionera]

As a sysadmin for a corporation with lots of compliance regulations, I want to be sure that my drives are properly sanitized when I deprovision a server. This includes support for the most common deletion sequences:

• DoD Formatting
• SCSI Self formatting
• NVME Format
• etc.

After a deletion is done, a log should be available containing all infos about the drives and their state in which they are to allow admins or third party vendors to verify that the drives where sanitized properly and can be reused/resold.

[lorenz]

If you care about data security, isn't cryptographic erasure via TPM nvindex wipe much safer? At least flash-based devices generally leave readable data on the flash chips. Even spinning disks don't just linearly map through all available space.

ATA secure erase / NVMe sanitize is the only thing which has any hope of actually deleting data semi-permanently. And even that has been proven to not work sometimes. ATA secure erase has known reliability problems with firmware issues and controller timeouts, NVMe sanitize is mostly restricted to certain enterprise drives.

The most I would offer is three options (and I already feel uncomfortable with that many):

1. Fast cryptographic erasure. Relies on the keys being destroyed by us. Only wipes partition table. Pseudorandom data is left on the devices. Takes seconds, very reliable.
2. Clear. Relies on the keys being destroyed by us but also makes a best-effort attempt to present the disk as clean to the next user. Uses NVMe format for flash devices. Writes zeroes to other devices and trims if available. Slow for spinning disks and old flash-based devices. Very reliable.
3. Sanitize. Uses NVMe sanitize, ATA secure erase or SCSI sanitize. Samples a few regions afterwards to check if no data is left. If not available on any disk the operation fails. Our security model still relies on cryptographic erasure, but assuming proper implementation by disk controllers the data can be expected to be permanently destroyed. Much less reliable than the other two, depends a lot more on sketchy firmware, long command timeouts and availability of specific optional functionality.