Which Secure Erase command will clear the HPA and DCO hidden areas? about openseachest

[vonericsen]

This is a great question!

I had to do some research and confirm with our spec representative in order to make sure I can give you an accurate answer.

For drives with HPA and DCO here is the interaction with hidden areas when using ATA security erase and Sanitize:

ATA Security Erase

• Normal Mode: DCO and HPA protected area is NOT erased
• Enhanced Mode: Protected area DOES get erased

Examples:
500GB drive with DCO or HPA configured to 250GB

• Normal mode: 250GB of data is erased
• Enhanced mode: 500GB of data is erased (+ previously reallocated sectors)

Sanitize
Protected areas SHALL BE erased

Example:
500GB drive with DCO or HPA configured to 250GB: 500GB of data is erased (+ previously reallocated sectors).

Please be aware that HPA was replaced with AMAC (Accessible Max Address Configuration) in newer ACS specifications and that DCO was made obsolete.
AMAC is different for these erases compared to HPA and DCO:

ATA Security and Sanitize
In all modes, all data will be cleared by these erases.

Example:
500GB drive with AMAC configured to 250GB: 500GB of data is erased.
NOTE: Previously reallocated sectors are only erased with Sanitize or ATA Security Erase in Enhanced mode

[vonericsen]

Do the firmware commands above that wipe these hidden areas also require this, or are the HPA/DCO/AMAC simply wiped by default every time the commands are run?

Based on my research and conversation with our spec representative, HPA/DCO/AMAC do not need to be disabled/removed for Sanitize or Enhanced ATA security erase to wipe these areas (and normal ATA security erase for AMAC).

If it's an HPA or DCO drive, and it only supports normal mode for ATA security erase, then this will be required. Some drives (especially older ones) do not support the enhanced mode for ATA security erase.

If you can remove these before the erase, it would make it easier to validate that they were in fact erased no matter which combination of features are in use or are used for the erase.

For HPA and AMAC, we have an option in openSeaChest_Configure called --restoreMaxLBA which will remove the protected area by making the native max or accessible max LBA back to the native max of the drive.
There are a couple potential problems that may occur depending on how the drive is attached and driver or hardware (USB bridges) function:

• If for some reason the command completion data (Return task file registers) are not available due to a hardware, firmware, or driver bug/limitation, it is not possible to read the native max LBA and restore back to original. Swapping to other hardware can get around this. Unfortunately this does happen often with USB adapters. It is less common in other scenarios, but not impossible to experience a similar problem with something like a SAS HBA.
• HPA can have a password set. If this is the case, it must be HPA unlocked before this can be done. I will say I'm not aware of any hardware or BIOS that uses this feature, but it should be pointed out in case an error is found.
• If an HPA command has been sent by anything else (other software, BIOS, etc), the drive must be power cycled before another HPA command to change native max LBA can be sent. A BIOS may be able to do this, but I haven't heard of it so far, but I have seen lots of strange things in the past. If this is the case, the drive will abort any other HPA request until it has been reset or power cycled (software usually cannot issue resets directly).

We do not currently have support for DCO options in the tools, but if desired, create a new Github issue and note it as a feature request and we'll look into adding them. DCO has its own similar issues. If a DCO freezelock has been issued, the drive will not process any DCO commands until power cycled (and maybe hardware reset). In this case, I have seen the BIOS from some system OEM's issue a DCO freezelock commands before the OS boots. To get around this you would need to use a non-ATA/AHCI card or adapter that would otherwise work...or use another system.

This same freeze-lock issue may also happen with ATA security. In this case, openSeaChest is able to detect the freezelock and report it. Windows will issue an ATA security freeze lock as soon as a drive is attached on a native ATA interface...using a SAS HBA or USB bridge, this doesn't happen (but it is possible any of these could choose to issue this command, but I have not experienced this myself). The exception to this rule is booting into Windows PE/Recovery environment, this does not happen unless the freeze lock was issued by the BIOS. In this case, Windows will only allow an erase to be started with a specific password. More details about this here. Note that this only affects ATA busses. This is not a problem in ATA over SCSI or USB/external adapters.

[hashimaziz1]

This is a great question!

I had to do some research and confirm with our spec representative in order to make sure I can give you an accurate answer.

For drives with HPA and DCO here is the interaction with hidden areas when using ATA security erase and Sanitize:

ATA Security Erase

* Normal Mode: DCO and HPA protected area is _NOT_ erased

* Enhanced Mode: Protected area _DOES_ get erased

Examples:
500GB drive with DCO or HPA configured to 250GB

* Normal mode: 250GB of data is erased

* Enhanced mode: 500GB of data is erased (+ previously reallocated sectors)

Sanitize
Protected areas SHALL BE erased

Example:
500GB drive with DCO or HPA configured to 250GB: 500GB of data is erased (+ previously reallocated sectors).

Please be aware that HPA was replaced with AMAC (Accessible Max Address Configuration) in newer ACS specifications and that DCO was made obsolete.
AMAC is different for these erases compared to HPA and DCO:

ATA Security and Sanitize
In all modes, all data will be cleared by these erases.

Example:
500GB drive with AMAC configured to 250GB: 500GB of data is erased.
NOTE: Previously reallocated sectors are only erased with Sanitize or ATA Security Erase in Enhanced mode

This is great information, thanks for the quick reply in spite of having to research the details, it's much appreciated.

Just to confirm, tools like hdparm first require removing the HPA and DCO areas before the area they occupied becomes available to wipe. Do the firmware commands above that wipe these hidden areas also require this, or are the HPA/DCO/AMAC simply wiped by default every time the commands are run?