Is there any way to verify a Secure Erase or Sanitize operation completed successfully? about openseachest

[vonericsen]

Great question!

As you mentioned, there are reasons why a command may not complete all the way due to the OS interrupting, or even a drive having an error.

The easiest way to perform the verification is to check some LBAs for their contents before erasing, then again after.
Using LBAs in the beginning, middle, and end of the range will help check it all. I use the term range since some options allow specifying specific ranges, while others always do the full drive, so keep that in mind no matter which use-case is being utilized.

If you use the --displayLBA option, it will dump the raw contents of a given LBA to the screen. You can use this to check before and after an erase.
If the LBA you choose is all zeros, you can use the --overwriteStart <lbaOfInterest> --overwriteRange <1 or more> --pattern random to place some data into the LBA.
I recommend writing random data like this, or a pattern of choice with the other options, so that it's easier to check. By default, any erase these tools perform write all zeros. Drive managed erase typically (but not always) defaults to writing zeros, which is why it's important to make sure there is a known data pattern in the LBA before you start an erase and you can then check again after the fact with the same option, at the same LBA.

Alternatively, if the erase method being used allows specifying a pattern, you can choose a specific pattern to erase the drive with and verify different LBAs contain that data after it completes. Some that I can think of that allow specific patterns are overwrite, sanitize overwrite, write same, & format unit (SAS).

Let me know if you have additional questions about verifying an erase.

[vonericsen]

Based on what you're saying above about the methods that can be used to verify a Secure Erase, am I correct in thinking that the results of a firmware erase can be verified in much the same way as a normal zero fill to the drive?
As long as the erase is writing zeros, this will work.

For ATA Security Erase in normal mode, the spec says the drive share writes zeros (00h) or ones (FFh) to the entire medium.
ATA Security Erase in enhanced mode, the spec leaves the data pattern up to the device vendor to decide. On non-SED Seagate drives, I believe it just writes zeros. On SED drives, the enhanced erase performs a cryptographic erase and the data is random once the key has changed (within seconds).

Other firmware erase like Sanitize Overwrite or Write same allow specifying a pattern, which openSeaChest (and SeaChest) default to using zeros. We do allow specifying patterns for these with other options though.

Cryptographic erase (such as Sanitize crypto or revertSP on an SED) is going to vary. On the SED drives I have done this on, the data comes out randomized after the cryptographic key is changed. I have heard that some other vendors may have the drive report zeros after a cryptographic erase, but I cannot confirm this.

Expecting zeros every time is not the best way to verify unless you know the data pattern being written.
That is why I mentioned using this option to get the raw data from a few different LBAs and comparing before and after is the best way unless you know the pattern.
If you use something like sanitize overwrite for the erase, I think you could reasonably expect all zeros since that is the default pattern used by these tools for that erase.

If this is true and Secure Erase/Sanitize can be verified by simply reading back the disk, rather than querying firmware, then this would allow me to continue using the simple workflow I'm currently using for verification. If it is true, would verifying this way have any disadvantages, apart from not being able to verify non-user-accessible areas like the HPA and DCO?
Yes, verifying the disc data is probably the best way. I'm not aware of any place on SATA or SAS drives that tell you if a drive has been written after being erased through a firmware command or not.
NVMe's sanitize status log does have a bit to identify if the drive is erased or not (with sanitize commands at least). When set to 1, it means no data has been written to it because it is either because it is brand new, or no writes have occurred since the last sanitize command was issued to it. It gets cleared to zero when any data has been written to it, or a persistent memory region has been enabled.

I hope this helps! Please let me know if you have other questions about this that I may be able to help with.

[hashimaziz1]

Based on what you're saying above about the methods that can be used to verify a Secure Erase, am I correct in thinking that the results of a firmware erase can be verified in much the same way as a normal zero fill to the drive?
As long as the erase is writing zeros, this will work.

For ATA Security Erase in normal mode, the spec says the drive share writes zeros (00h) or ones (FFh) to the entire medium.
ATA Security Erase in enhanced mode, the spec leaves the data pattern up to the device vendor to decide. On non-SED Seagate drives, I believe it just writes zeros. On SED drives, the enhanced erase performs a cryptographic erase and the data is random once the key has changed (within seconds).

Other firmware erase like Sanitize Overwrite or Write same allow specifying a pattern, which openSeaChest (and SeaChest) default to using zeros. We do allow specifying patterns for these with other options though.

Cryptographic erase (such as Sanitize crypto or revertSP on an SED) is going to vary. On the SED drives I have done this on, the data comes out randomized after the cryptographic key is changed. I have heard that some other vendors may have the drive report zeros after a cryptographic erase, but I cannot confirm this.

Expecting zeros every time is not the best way to verify unless you know the data pattern being written.
That is why I mentioned using this option to get the raw data from a few different LBAs and comparing before and after is the best way unless you know the pattern.
If you use something like sanitize overwrite for the erase, I think you could reasonably expect all zeros since that is the default pattern used by these tools for that erase.

If this is true and Secure Erase/Sanitize can be verified by simply reading back the disk, rather than querying firmware, then this would allow me to continue using the simple workflow I'm currently using for verification. If it is true, would verifying this way have any disadvantages, apart from not being able to verify non-user-accessible areas like the HPA and DCO?
Yes, verifying the disc data is probably the best way. I'm not aware of any place on SATA or SAS drives that tell you if a drive has been written after being erased through a firmware command or not.
NVMe's sanitize status log does have a bit to identify if the drive is erased or not (with sanitize commands at least). When set to 1, it means no data has been written to it because it is either because it is brand new, or no writes have occurred since the last sanitize command was issued to it. It gets cleared to zero when any data has been written to it, or a persistent memory region has been enabled.

I hope this helps! Please let me know if you have other questions about this that I may be able to help with.

This makes a lot of sense, I just assumed that most of the firmware erases would write zeroes by default, but you make a good point that this needs to be verified first. I was just surprised to know that the results of a firmware erase can be verified by checking the raw disk, but that does also make sense, and is good news. Thank you for your extensive help on this.

[hashimaziz1]

Great question!

As you mentioned, there are reasons why a command may not complete all the way due to the OS interrupting, or even a drive having an error.

The easiest way to perform the verification is to check some LBAs for their contents before erasing, then again after.
Using LBAs in the beginning, middle, and end of the range will help check it all. I use the term range since some options allow specifying specific ranges, while others always do the full drive, so keep that in mind no matter which use-case is being utilized.

If you use the --displayLBA option, it will dump the raw contents of a given LBA to the screen. You can use this to check before and after an erase.
If the LBA you choose is all zeros, you can use the --overwriteStart <lbaOfInterest> --overwriteRange <1 or more> --pattern random to place some data into the LBA.
I recommend writing random data like this, or a pattern of choice with the other options, so that it's easier to check. By default, any erase these tools perform write all zeros. Drive managed erase typically (but not always) defaults to writing zeros, which is why it's important to make sure there is a known data pattern in the LBA before you start an erase and you can then check again after the fact with the same option, at the same LBA.

Alternatively, if the erase method being used allows specifying a pattern, you can choose a specific pattern to erase the drive with and verify different LBAs contain that data after it completes. Some that I can think of that allow specific patterns are overwrite, sanitize overwrite, write same, & format unit (SAS).

Let me know if you have additional questions about verifying an erase.

Based on what you're saying above about the methods that can be used to verify a Secure Erase, am I correct in thinking that the results of a firmware erase can be verified in much the same way as a normal zero fill to the drive?

Sure enough I just finished a test that ran an enhanced Secure Erase and then verified with the custom tool that I usually use to check for any non-zero characters in a file, and sure enough it seemed to confirm that the entire drive had been zeroed (non-SSD drive, so wear levelling and other such features can be safely ruled out).

If this is true and Secure Erase/Sanitize can be verified by simply reading back the disk, rather than querying firmware, then this would allow me to continue using the simple workflow I'm currently using for verification. If it is true, would verifying this way have any disadvantages, apart from not being able to verify non-user-accessible areas like the HPA and DCO?

[vonericsen]

You are welcome!

If you have more questions, please ask!
I am happy to answer them as best I can, if if there is a good place to document this type of information that you think would be helpful (in the help, user guides, or somewhere else), please let me know.