Documentation regarding Sanitize commands

[fthobe]

The secure erase matrix on the seagate website illustrates the compatibility of devices to the various sanitize block commands across different interface standards (NVME / SAS / SATA). The documentation has some inconsistency with other documents from seagate though: While the secure erase matrix (see screenshot) states that NVME devices do not support sanitize, the documentation of the devices itself (6.2.3, p.22) indicate the availability of sanitize commands.

This raises some questions:

1. Which documentation is incorrect or unclear?
2. Does the nvme version of OpenSeaChest support sanitize?
3. Does hdparm in case of sata disks for example using command hdparm --yes-i-know-what-i-am-doing --sanitize-block-erase /dev/sdx create the same outcome as the seachest sanitize implementation?
4. Do sg3_utils in case of SAS disks for example using the command sg_sanitize --block /dev/sdm create the same outcome as the seachest sanitize implementation?
5. Does the open source nvme-cli when using the commands outlined in the documentation of the nvme-cli create the same outcome as when using OpenSeaChest?

Thank you

[vonericsen]

Hi @fthobe,

Sorry for not seeing this question sooner!

Which documentation is incorrect or unclear?

I believe this chart was created prior to the sanitize feature being standardized in the NVMe spec.
I will see if I can get that updated.

Please also be aware that not every device will support all of these features, even if they are listed as available on a given interface/configuration.

For example: Not all SATA drives will support the sanitize feature set, especially old drives, and even those that do will only support the overwrite unless they are SED. Block erase will only ever be on SSD's as well, so that will not be available on HDDs and this chart is unable to capture that level of detail, although I can ask about adding some of these additional notes to the page.

In openSeaChest_Erase, we have the option --showEraseSupport which queries the drive for which methods of data-erasure are supported. Part of the last release was also indicating in this output whether the supported erasure's are considered purge or clear according to the IEEE-2883r2022 standard for data sanitization.
The current version of SeaTools is using this same method as well to determine what is or is not supported when providing options to the user.

Does the nvme version of OpenSeaChest support sanitize?

While openSeaChest_NVMe is specific to NVMe, all of the openSeaChest tools support NVMe devices. Not all features found on NVMe will be part of openSeaChest_NVMe although this is where many NVMe unique data and capabilities have been put for now.
In the case of Sanitize, openSeaChest_Erase will support Sanitize operations on SAS, SATA, and NVMe devices (USB device may vary by adapter).

Does hdparm in case of sata disks for example using command hdparm --yes-i-know-what-i-am-doing --sanitize-block-erase /dev/sdx create the same outcome as the seachest sanitize implementation?

To the best of my knowledge, this will do the same thing as openSeaChest_Erase -d <handle> --sanitize blockerase --poll --confirm this-will...
I'm in process of a new release that will allow specifying to run in unrestricted mode as well with another option on the command line, but I do not know if hdparm supports that or not.
By default openSeaChest runs in the more secure restricted mode of sanitize.

Do sg3_utils in case of SAS disks for example using the command sg_sanitize --block /dev/sdm create the same outcome as the seachest sanitize implementation?

Yes, for SAS disks it will. For SATA disks on SAS HBA's it should also work if the controller supports the translation of the T10 Sanitize CDB to T13 (ATA)'s sanitize as specified in SAT. I believe Broadcom's 9400's will do this, and 9300 might as well, but I have not tested that in a while so my memory isn't as good 😄 Microchip controllers of the same age (don't remember a model number) will likely also support this translation.
This translation was added in SAT-3. Keep in mind that even if an HBA says it supports SAT-3, it may not support all translations present in that standard (I have run into this issue many times).

Does the open source nvme-cli when using the commands outlined in the documentation of the nvme-cli create the same outcome as when using OpenSeaChest?

Yes, that will do the same sanitize commands openSeaChest_Erase supports for NVMe devices.

Additional information that may be relevant to this question

One other thing that many people using or attempting to use the sanitize command set may run into is sometimes the commands may be blocked. In Windows, starting with Windows 8 you cannot issue this command unless you are in the PE/RE environment for SAS and SATA.
Starting in Windows 10 23h2 (I think that was the update) it was allowed on NVMe devices that are not the boot-drive, but only crypto and block erase is supported, but you cannot poll for progress....you just wait until the OS returns from that IOCTL.

You can configure TCG (Opal/Enterprise/etc) drives to block these commands as well.

Some USB adapters will not support issuing these commands because they do not support more than the basic identify and SMART commands in passthrough.

Another thing some users have seen, especially with sanitize overwrite, is that it takes a very long time...longer than the approximation of 2hours per TB. This can happen because some HBAs/Drivers do not understand that when the drive is sanitizing, it does not allow a lot of commands and is very limited....they will then begin issuing reset after reset to the drive, slowing the sanitize, trying to "recover" the drive.
When this happens, pulling the interface, but leaving the power attached will allow it to continue and complete uninterrupted.

[fthobe]

Hi @vonericsen ,
thank you so much for your extensive reply and first of all thank you for your contributions to Seachest, you did an awesome job. I hope I can bother you with some more questions :)

I believe this chart was created prior to the sanitize feature being standardized in the NVMe spec. I will see if I can get that updated.

That would be awesome. If you could put hand on a per SKU compatibility matrix you would be my personal hero. It seems to be immensely difficult to poll manufacturers for that information.

Please also be aware that not every device will support all of these features, even if they are listed as available on a given interface/configuration.

Do you know from your experience if nvme id-ctrl -H always yields a correct output on Seagate devices? Not all manufacturers have always been 100% compliant with optional interface standard features (despite admitting that Seagate and WD are definitely most complete in documentation).

# nvme id-ctrl -H /dev/nvme1
...
  [2:2] : 0   Overwrite Sanitize Operation Not Supported
  [1:1] : 0x1 Block Erase Sanitize Operation Supported
  [0:0] : 0   Crypto Erase Sanitize Operation Not Supported
...

In openSeaChest_Erase, we have the option --showEraseSupport which queries the drive for which methods of data-erasure are supported. Part of the last release was also indicating in this output whether the supported erasure's are considered purge or clear according to the IEEE-2883r2022 standard for data sanitization.
The current version of SeaTools is using this same method as well to determine what is or is not supported when providing options to the user.

That's immensely helpful. IEEE-2883r2022 is in large part built on NIST 800-88, NIST 800-88 also asks for the method (overwrite / block erase / crypto erase / other physical destruction options), is there any chance that information could find it's way in --showerasesupport as well?

Edit: fixed typo

[vonericsen]

@fthobe,

That would be awesome. If you could put hand on a per SKU compatibility matrix you would be my personal hero. It seems to be immensely difficult to poll manufacturers for that information.

I found someone who can update the chart, but I do not think I'll be able to get to SKU level of information. I'll bring this up with that team and see what this would take though.

Do you know from your experience if nvme id-ctrl -H always yields a correct output on Seagate devices? Not all manufacturers have always been 100% compliant with optional interface standard features (despite admitting that Seagate and WD are definitely most complete in documentation).

For all of the Seagate NVMe devices I've tested, they are all compliant with the standards for reporting which optional features they support. Seagate does a LOT of testing to make sure they are compatible with standards.
OpenSeaChest also relies on these standardized fields for everything we implement...openSeaChest always starts with what the standards document and we implement workarounds only as needed (which isn't often for things that are standardized).
I would expect that when issuing a command like that, whether from openSeaChest or nvme-cli or hdparm or sg3utils or camcontrol or smartmontools that anything in a standard should work and be accurate.

When openSeaChest is used on non-Seagate devices, it relies on the same standardized fields and behavior to support those products as well. I do not get non-Seagate devices to test very often, but occasionally I get a bug report or some information that I can use to make updates as needed, but generally anything that reports something standard has seemed to work as expected from my perspective.

One thing to keep in mind is that features can change between product generations.
For example, the Firecuda 510 does not support Sanitize or DST as it was built before those features were standardized in NVMe.
The Firecuda 530 has these features as they were part of NVMe by the time it was built. (I don't remember the 520 and what it supported off the top of my head).
It is rare to upgrade firmware for a product to a new standard during its life, but it can happen in some circumstances. Generally new features will not be added once a product is released, usually just updates to fix firmware bugs that are found over time while providing product support to customers.

That's immensely helpful. IEEE-2883r2022 is in large part built on NIST 800-88, NIST 800-88 also asks for the method (overwrite / block erase / crypto erase / other physical destruction options), is there any chance that information could find it's way in --showerasesupport as well?

I can look into what else we can put to describe each erase. It's been a while since I last reviewed NIST 800-88.
Would it be helpful just to make "This is an overwrite", "This is a cryptographic erase", etc?
With Sanitize this is easy, but ATA security is complicated due to vendor unique behavior on enhanced secure erase.
NVMe's format secure erase may also get complicated if the drive supports crypto erase since a request to crypto erase will do crypto erase and a request for user data erase is left to the vendor to decide if it also does crypto erase or something else.
For these cases we would probably want something like "Possible crypto, possible block, etc" but I want to make sure this is clear for a user to see and understand since I know all these "Vendor unique" things gets to be a bit of a mess.

[vonericsen]

@fthobe,

I have confirmation that the English language page for the erase matrix has been updated. (Note: If you are outside the US, you may need to click on the globe at the top of the page and change it to United States (English) due to automatic redirects)

This went live a few minutes before this comment so it make take a little time before for it to update through all the server caching for general users.

The web team will be working on getting it translated to other languages as well, but that will take about a month before it is completed.

[fthobe]

@vonericsen
In a previous iteration of this comment, I assumed it wasn't updated. My mistake, thank you!

Some notes:
Following is written in the page:
[...]
All sanitize = purge
Revert and RevertSP = purge on Opal, Enterprise, Ruby, and Opalite
[...]

Do Opal drives support Sanitize commands or are the Revert and RevertSP commands intitiated by regular sanitize commands?

[vonericsen]

An Opal device may support the sanitize command set, but it is not guaranteed.
I have seen some customer unique firmware configurations without Sanitize (rare and unlikely to be seen by most users unless you buy a very specific used drive off the web) and some very old Opal drives that do not have sanitize as the sanitize feature was not yet defined in a standard.

All that said, all of Seagate's HDDs with Opal support since Sanitize was added in ACS-2 (approximately 2014 designs. Note: There were models manufactured this year that would not have sanitize which is why I used the term designs in this case) seem to have support for the sanitize command set. Seagate's Enterprise TCG drives (SAS and some SATA) also support sanitize since this time.

Revert and Revert SP are considered Purge on Opal as they cause a cryptographic key change, just like the sanitize crypto erase feature. Seagate rolled this out as ISE or Instant Secure Erase originally, but I will come back to this later in this comment.
There are other methods within TCG that you can use to change cryptographic keys as well but these are the two people use most. Some of the other methods allow changing keys per LBA range that was configured on the drive wheras revert and revertSP change the key(s) for all LBA space on the drive.

On Seagate HDDs (and SAS SSDs) all of the SED model drives support issuing RevertSP with the drive's PSID from the label regardless of whether you have enabled the locking SP (Security provider) in the drive and it will always cause a Cryptographic erasure of all user data. This also restores all drive configuration back to the default factory settings. This applies not only to TCG Opal, but also TCG Enterprise drives from Seagate.

For other Seagate SSDs and some other drive vendor's Opal drives that I have run into, the revertSP is not always available with the PSID without the locking SP enabled. I have also found that if you do a revert on the Admin or Locking SP and it has not had the locking SP enabled, it does NOT perform a cryptographic erase. I did a lot of rereading of the TCG Opal spec and this is allowed, just like Seagate's "You can always do revertSP and change the crypto key" is allowed.

An important note about TCG is that there are ways to configure the TCG feature to block commands like Sanitize from running so that the user must do either revert or revertSP instead before the drive will accept those commands (or, if the TCG software allows for it, unblocking sanitize).

Going back to "ISE" again, before the sanitize feature was standardized, Seagate also sold "ISE" capable drives that were not Opal drives along with the Opal offersing. These used a Seagate vendor unique TCG SSC that was capable of revertSP to change the crypto key on the drive.
I have seen at least one Fibre Channel drive that was old with TCG Enterprise support that had the MSID on the label instead of the PSID. It required a different method to do the cryptographic erase, but these drives are so old now I don't think any of them are still "alive".

All of these little details about differences are part of the reason we have not yet brought the TCG support to openSeaChest.

One other thing I have very recently started doing is putting together the openSeaChest wiki pages.
This one may be most relevant for what you are asking about.
I still have a lot more documentation to write up for the Wiki (including this TCG information), but I will get it up there as well as I find the right pages to put this information on (I have a lot of pages in progress that I'm working on before I post them).

One final note, all modern Seagate drives will have a PSID on the label. This does not mean it is a TCG Security enabled model. The use of the PSID for non-SED models is part of Seagate's secure supply chain.

[fthobe]

Hey @vonericsen, first things first. Man, you are amazing. You gave such a transparent view on everything.

I am working very hard on getting a clear idea about how to unify everything, but honestly, I am getting stonewalled by a lot of manufacturers and would really like to get in touch with somebody.

Is there any chance I could get you on board on a call with some other folks of nwipe and shredOS? I am walking down all possible alleys but:

• all the software pre NVME is closed source (with me having a new Seagate shaped spot in my heart)
• documentation is spotty at best, I just have no insurance of any drive really fully executing anything;
• There's no support matrix by drive SKU of any disks.

I had high hopes for Intel, but even there since solidigm runs the show, hardly any info. I am having the feeling that many existing software tools just claim to wipe stuff and ignore implementation differences in between drive models.

I feel we would really benefit from interviewing you.

Do you feel that's a possibility?