openSeaChest instead of hdparm for ATA Erase?

[git70]

While looking for reliable information about Enhanced Security Erase, I found wiki openSeaChest:
https://github.com/Seagate/openSeaChest/wiki/ATA-Security-Feature#security-erase

Does anyone have experience in using openSeaChest_Erase compared to hdparm?

I don't know if this idea is idiotic, but did you consider to replace hdparm SE by openSeaChest_Erase when the ATA Secure Erase service comes directly in GUI ShredoOS?

Does it make sense and any advantage?

[Firminator]

Does anyone have experience in using openSeaChest_Erase compared to hdparm?

That's a loaded question :) I haven't seen any posts about it yet.

consider to replace hdparm SE by openSeaChest_Erase

This idea was discussed or at least brought up before. Can't find the thread anymore though.
It makes sense to me as we are not introducing additional dependencies but rather replace one tool with another. It's just hard to decide if hdparm of openSeaChest is broader supported/accepted, has better fleshed out hardware support, and which of the two is more likely to be the golden standard go-to-tool in the future for Secure Erase/Sanite/Enhanced SecureErase.

Good starting point would be to check out the thread when the developer of openSeaChest (@vonericsen) was formally introduced by @fthobe to the nwipe repo @ martijnvanbrummelen/nwipe#641

There is also a thread from @fthobe with compiled data of drive manufacturers supporting which methods and tools for secure erase @ martijnvanbrummelen/nwipe#591 ; bonus: a Samsung engineer gave his 2 cents :)

[fthobe]

@Firminator thanks for tagging :)
@git70

General warning and TL;DR
Support is shady as f*ck.
excuse the vocabulary, but yes, it's exactly that. You do not have 100% security on anything that's not a <10 year old sata / sas / nvme drive coming from WD or Seagate (if it's genuine, which is a big if on SSD). The SATA standard had multiple iterations of sanitize and the best way (as there aren't any complete support matrixes) is verify firmware support and afterwards contact the manufacturer to verify preferably by reading the original data sheet of the drive and tracing firmware update change notes. Do keep in mind that also the meaning of sanitized changed over the past 25 years (from deleting to effectively sanitizing). Your desired level of security is the imperative here: if you are doing it to cover up some downloaded movies polling the firmware is fine, if you are working in defence, infrastructure or healthcare you probably want to physically shred the disk if it's decommissioned AND moved out of your Organization. On SSDs you 100% rely on the firmware responding correctly and I wouldn't rely on that at all on anything but <5 year old drives from known manufacturers. As you can read I am hesitant to give you a thumbs up on anything and that's a result of months of research around this topic as @Firminator explained, rotary disks you can check with your own tools sector by sector, on SSD you can't reliably.

Longer version
So, there are some considerations here:

@PartialVolume has integrated openseachest into shredos after talking to @vonericsen and there are multiple topics open around this:

Generally you can say that firmware development of sata and sas has ceased in large parts, NVME is here to stay as it seems on servers as well as clients.

You are in the process of climbing down the rabbit hole I went down on the by now "legacy" systems: spotty docs (seagate is still documenting better than others).

General Rule of thumb:

• drive from the past 15 years from reputable manufacturers return (if no firmware bug is present) the sanitize compatibility correctly (also on hdparm), but even seagate or Samsung firmware developers say that with a disclaimer.
• same goes for SAS with different commands in sg3_utils creating the same outcome
• same goes for nvme using nvme-cli

Reputable: WD, Samsung, Solidigm (Intel)

To check if a drive can be sanitized use:

hdparm --sanitize-status /dev/sdx

# if not supported by the drive you will read
/dev/sdx:
SANITIZE feature set is not supported

There is an equivalent command on seachest.

@vonericsen did really great here by adding a NIST vocabulary (clear / purge / sanitize) to seachest.

Disk support in general

You can cluster it into three large blocks:

SATA

• rotating sata (shredOS sanitizes without problems)
• ssd sata (we assume that hdparm does sanitize and it seems that support is correctly returned by the firmware in case of major brands)
• OEM Chinese non major label brand SSDs are the unknown as they 1) do not respect the standards 2) often even violate the standards (you will find that some Chinese brands use the same serial numbers on all disks for example), destruction is the only way here

NVME
I checked roughly 30 drives and they seem to reset fully if from a reputable brand, I wouldn't trust anything non major (crucial is already so so for me as documentation is non existing for older drives).

sas
I am adding this as it's good know. You asked for hdparm which handles only sata disks, but let's be complete. It's a little easier here as there are almost no OEM brands in this sector and adherence to standards is incredibly high for datacenter disks.

It was mentioned in some discussions that some opal drives do behave erratically.

[vonericsen]

As @fthobe pointed out the biggest issue around secure erasure is verifying the erase, especially on some of the SSDs that were mentioned that do not really follow the spec.

In all the standards (T10, T13, and NVMe) there have been efforts to help with this. There are bits to tell the device not to perform any kind of TRIM/Deallocate/Zone Reset when sanitize is run (or ATA Security erase).
On SAS/SATA the bit is called Zone No Reset or ZNR and NVMe used the wording No Deallocate after erase. These are more or less the same meaning all around, but SAS/SATA used ZNR as there has been little to no changes for SSDs in these specs in a while and this term is focused on host-managed zoned block devices. Almost all changes are being driven by HDDs in T10/T13 since SSDs have largely moved to NVMe.

In openSeaChest I did add some more info about this to the --sanitize info option, especially for NVMe since that no deallocate info can be reported with a few different states depending on some feature configuration.
I also added support to pass the options --znr or --nodeallocate when running Sanitize (and ATA security erase for SATA drives) so that verification is easier to perform.

One other thing we don't currently have is using the LBA status log to check if the LBAs were deallocated after erase or not. If this is of interest, please create an issue on openSeaChest and I can look into adding it. That log is getting some attention for HDDs now too for other uses, but it's been around for SSDs to note if various LBAs have been trimmed or not.
This may not solve the issues @fthobe mentioned, but it may help make things more clear when a drive properly supports them.

[vonericsen]

I am obviously biased towards openSeaChest, however I have assisted Seagate's customers with using just about every other opensource tool out there (hdparm, sdparm, sg3utils, smartmontools, camcontrol, nvme-cli, etc) so I'm fairly familiar with those as well.

I'm going to follow the comments on here so I can see any feedback others have had with openSeaChest so that if there is something we can work on improving I can take note of it.

I also want to encourage those who have run into something they are having trouble with to open issues or discussions on the openSeaChest repo so we can help with them! 😄

[fthobe]

@vonericsen you are right, you have helped so much, @git70 should be fully informed :)

The following link gives you a great idea how to use openSeaChest with shredOS (it comes prepackaged).
https://github.com/Seagate/openSeaChest/wiki/Sanitizing-Storage-Devices

You can invoke it through the virtual terminal as described here.