-
Notifications
You must be signed in to change notification settings - Fork 62
Sanitize Feature
The sanitize feature is one of the newest features available on SATA, SAS, and NVMe devices through standardization, however it is an optional feature in each of the standards.
Starting with ACS-2, Sanitize was made available for SATA devices following this standard.
For SAS devices, support started with SBC3.
NVMe adopted the sanitize feature in the NVMe 1.3 standard.
Across all these standards, the core of sanitize is the same with only minor differences between devices. The purpose of this feature is to ensure all user data is removed as securely as possible from the storage device. Sanitization occurs for all user accessible blocks up to the native max user addressable block, bad blocks, overprovisioning, spare blocks. Essentially any block within the device that currently stores user data, has stored user data in the past, or could store user data in the future will be sanitized from the device. All methods of data sanitization supported by this commandset are considered IEEE-2883r2022 purge compliant.
As of writing (September 5, 2024), there are up to three methods for sanitization: Crypto erase, Block erase, and Overwrite erase. There are also 2 modes which sanitize may run in: Restricted mode and Unrestricted mode.
All standards (T10, T13, nvmexpress) describe ways to determine if the device supports these commands which should be used to determine when these methods are supported under this feature. openSeaChest_Erase uses these methods to determine when these commands are supported by a device.
While Sanitize is similar to ATA Security Erase Enhanced, it does behave differently: It is pollable to determine the progress.
Once a sanitize feature has been started it cannot be stopped by any command or even by removing power from the device. As soon as the device loses power it will automatically restart where it left off until the sanitize has completed or entered a failure state (See Sanitize modes below for details about failure state).
While a device is sanitizing, it has a limited set of other commands it will process without an error. These allowed commands can be summarized as not accessing user-data, not changing device behavior and not changing device configuration while sanitize is running or in failure state.
Not all devices support cryptographic erasure. This option is most often found only on SED (Opal, Enterprise, etc TCG features).
When issued a cryptographic erase request, this instructs the device to randomly generate a new encryption key, instantly making all user data on the device inaccessible since the key cannot be recovered or reversed.
Once a cryptographic erase has been performed, all data read back may be random, or some devices may return zeroes in place.
A Sanitize crypto erase may be desribed as an Instant Secure Erase (ISE) by some vendors and software.
Example of executing Sanitize Crypto Erase with openSeaChest_Erase: openSeaChest_Erase -d <handle> --sanitize cryptoerase --poll --confirm this-will...
Sanitize Block erase is typically supported on SSDs as a way to instruct the controller to issue the erase command to the NAND memory it manages.
NAND memory operates with program and erase instructions to tell it what bit values to hold or when to erase the chip, so this is a "shortcut" to skip reprogramming the NAND and simply erase it.
A block erase may take seconds or minutes to complete depending on the way the controller's firmware is programmed and the capacity of the device.
Example of executing Sanitize Block Erase with openSeaChest_Erase: openSeaChest_Erase -d <handle> --sanitize blockerase --poll --confirm this-will...
Sanitize Overwrite is as it sounds: an overwrite of all blocks that can hold user-data with a specific pattern.
Sanitize overwrite accepts a 32bit pattern on SATA and NVMe and for SAS devices it may accept up to a single logical block length pattern. OpenSeaChest only supports supplying a 32bit pattern in all cases. By default, the pattern used by openSeaChest is all zeroes: 00000000h
For HDD's the pattern is written to all blocks and a time to erase with this method is approximately 2 hours per terabyte of capacity.
For SSD's all NAND blocks are erased, then programmed with the pattern. Erase time varies depending on the firmware capabilities and capacity of the device.
This method supports between 1 and 16 overwrite passes to be managed by the firmware on SATA and NVMe devices. SAS devices support between 1 and 32 overwrite passes to be managed by the firmware. A device is only required to support 1 overwrite pass, but may support more than 1. The more passes requested, the longer a sanitize overwrite will take to complete.
Starting in the openSeaChest v24.08 release, the option to specify multiple overwrite passes has been added. By default only one pass will be used. Additionally, there is an option to instruct the firmware to invert the pattern between each overwrite pass that is also supported.
Example of executing Sanitize Overwrite Erase with openSeaChest_Erase: openSeaChest_Erase -d <handle> --sanitize overwrite --poll --confirm this-will...
Example of providing a pattern, multiple passes, and inverting between passes: openSeaChest_Erase -d <handle> --sanitize overwrite --overwritepasses 4 --ipbp --poll --confirm this-will...
Restricted sanitize mode is the default mode used by openSeaChest. In restricted mode a sanitize must always complete with success to be able to read the device again.
If a failure mode is entered during a sanitize operation, the device will continue blocking all read and write access to the device until a sanitize operation is able to complete with success. This protects any data that was unable to be sanitized from being accessed over the drive's interface. There is no way out of a failure mode other than a successful sanitize command.
Unrestricted mode can be used during sanitize in openSeaChest_Erase with the --ause option which means Allow Unrestricted Sanitize Exit. This option was added in the v24.08 release.
In this mode if a sanitize enters a failure state, the Exit failure mode command can be used. While in failure mode, the device blocks all reads and writes to user data, but once the command to exit this mode has been issued, reads and writes can be performed once again over the drive's interface.
This may be desired to verify what data was erased or to allow the user/host to attempt other methods of data sanitization. Typically if a failure is encountered during a sanitize, the device will not allow other methods of sanitization to succeed.
Both NVMe and ZBD specifications added other fields to help with verifying a sanitize completed as expected upon completion most specifically targetting Zoned Devices.
In T10 and T13 (SATA and SAS) the ZNR option was added to tell zoned devices not to reset the write pointers when sanitize is complete so that the entire device can be read and verified.
In NVMe, then No Deallocate option was added for the same purpose, but is not specifically described as only for Zoned devices.
OpenSeaChest_Erase supports passing either the --znr or --nodeallocate option to set these fields. Either of these options can be used on any device type. NVMe is not restricted to --nodeallocate. --znr will set the same bit as the --nodeallocate option for NVMe devices and visa-vera for SATA and SAS devices. Both options are provided so that depending on which specification a user is more familiar with, they can pass the one they recognize and get the result they expect.
Sometimes a system/HBA/driver may not understand that a sanitize is in progress and instead think something has stopped working on the device. When this happens it will attempt recovery by resetting the device...sometimes over and over again. While a device is sanitizing, it must respond to these resets, save it's progress, reset, then restart sanitizing again. All of these interruptions add up over time and slow down the process of sanitizing the device.
This will most likely be seen during an overwrite since that takes the longest to complete.
To work around this, you may disconnect the interface cable and leave only the power attached to the device. The interface cable is not needed to continue running a sanitization, only the power must remain attached to the device.
Starting in Windows 8 sanitize is blocked by the OS. The only time Sanitize is allowed is in PE or RE mode. In these modes, the command is not blocked.
Starting in Windows 10 22H2, NVMe storage devices may be issued Sanitize Crypto erase or Sanitize Block erase if and only if the device is not the boot drive.
If your NVMe device is managed by the Intel consumer NVMe driver, Sanitize will be blocked.
If your NVMe device is managed by the openFabrics driver as it was last written to NVMe 1.2, sanitize will be blocked. Modified versions of this driver may permit this to complete, but no modified versions are known by the team working on openSeaChest.
openSeaChest will always issue Sanitize commands through a known passthrough method, unless the --forceSCSI option is given.
Not all translators will support translation from a SCSI CDB to the target device.
In some cases in Windows, a SAT ATA-passthrough CDB for sanitize may get around the blocks noted above with SAS/SATA controllers or USB adapters capable of SAT ATA-passthrough.
SNT is still under development at the time of writing and the earlier SCSI to NVMe translation whitepaper does not describe any method to translating a SCSI Sanitize command to an NVMe device. That said, Broadcom has shared their translation document with the T10 committee which does include a translation for NVMe devices attached to Broadcom controllers.
For the most part, USB adapters follow what is described above for SAT and SNT since USB is often just a translator chip. Some USB adapters may not be capable of translating the Sanitize command or may not support the ability to pass-through a Sanitize command as they may be limited to only Identify and SMART data. Some adapters may be capable of more than these commands, however only 28-bit commands whereas SATA's Sanitize command is a 48bit command and cannot be issued in this limited passthrough.
Bad blocks have already been determined to be bad and not hold data, so how are they erased?
The firmware of a device is supposed to do a best attempt to remove data from bad blocks. If a failure occurs to change the data in a bad block, the firmware moves on. The purpose it to change any bits that may still be the original valid data from these locations to make them even less likely to be recovered.
Will this affect the wear leveling of the medium?
Depending on the type of sanitize requested, this may impact the wear leveling of the storage medium. A crypto erase likely will not affect it, but a block erase or overwrite are more likely to cause more wear on the device.