Should a secure ATA erase be performed on a non-SSD drive?

Question

When running the command hdparm -I /dev/sda the following output is generated.

ATA device, with non-removable media
        Model Number:       WDC WD10JPVX-75JC3T0                    
        Serial Number:      WX51A9324970
        Firmware Revision:  01.01A01
        Transport:          Serial, SATA 1.0a, SATA II Extensions, SATA Rev 2.5, SATA Rev 2.6, SATA Rev 3.0
Standards:
        Supported: 9 8 7 6 5 
        Likely used: 9
Configuration:
        Logical         max     current
        cylinders       16383   16383
        heads           16      16
        sectors/track   63      63
        --
        CHS current addressable sectors:    16514064
        LBA    user addressable sectors:   268435455
        LBA48  user addressable sectors:  1953525168
        Logical  Sector size:                   512 bytes
        Physical Sector size:                  4096 bytes
        Logical Sector-0 offset:                  0 bytes
        device size with M = 1024*1024:      953869 MBytes
        device size with M = 1000*1000:     1000204 MBytes (1000 GB)
        cache/buffer size  = 8192 KBytes
        **Nominal Media Rotation Rate: 5400**

Of interest is the description and value Nominal Media Rotation Rate: 5400. This indicates that the hard drive is mechanical and not flash.

There is support for ATA secure erase as suggested by the output albeit I would have not anticipated a secure erase taking as long as 198 mins.

Security: 
        Master password revision code = 65534
                supported
        not     enabled
        not     locked
        not     frozen
        not     expired: security count
                supported: enhanced erase
        198min for SECURITY ERASE UNIT. 198min for ENHANCED SECURITY ERASE UNIT.

Given that the device is not a solid state drive, should a secure ATA erase still be performed?

If no, why? If yes, why?

Would shred --verbose --random-source=/dev/urandom -n1 /dev/sda support the same or a similar outcome i.e. irrecoverable data including defective or deallocated sectors?

Answer 1

Given that the device is not a solid state drive, should a secure ATA erase still be performed?

If you want to erase the data, you can use ATA Secure Erase. It is not meant only for solid state drives and works fine on spinning rust. It takes a lot longer than on SSDs because hard drives are less likely to support SED, which allows instant erasure by destroying an encryption key.

Whether or not you use the firmware's secure erasure or erase the block device is something that is up to you. Both options come with advantages and disadvantages. For example, ATA Secure Erase is designed to erase areas of the drive that may not be touched by writing to the block device, such as damaged sectors and the HPA (Host Protected Area). On the other hand, any erasure implemented in firmware may be broken or implemented incorrectly, as you have no ability to easily tell how it is performing erasure. If you have time, you can perform both methods to get the best of both.

Would shred --verbose --random-source=/dev/urandom -n1 /dev/sda support the same or a similar outcome i.e. irrecoverable data including defective or deallocated sectors?

No, that would not erase damaged sectors, nor would it erase areas of the disk like the HPA. Note that the command you gave is functionally equivalent to cat /dev/urandom > /dev/sda. You can, however, use smartmontools to determine how many damaged sectors your drive is reporting. If the value is zero, then every accessible sector can be wiped just by writing to the block device.

If you want to overwrite the block device, you can do so with dd:

dd if=/dev/urandom of=/dev/sda bs=256k conv=fsync

This will write random data to the block device, and will sync the changes as soon as it has completed. On older Linux kernels, the random driver is very slow, in which case you should use other sources of randomness, for example creating an encrypted device with cryptsetup and writing zeros to it.

---

In the future, there is a technique you should utilize to ensure you are not put into this position again. You should use full disk encryption with something like LUKS, which keeps the randomly-generated master password on the drive, encrypted with a user password you specify. Simply overwriting the encrypted master password is sufficient to render all other data on the drive completely irrecoverable. This works for hard drives where there is no wear leveling in place. On solid state drives, this will not work.