Secure Erase SSD with hdparm

The secure erase feature of SSDs is brilliant when you want to wipe a disk to sell or rebuild or whatever because it takes seconds to nuke the entire disk compared to hours doing a zero wipe on a spinning hard drive. For example, zero wiping a 2TB drive takes me roughly 26 hours compared to roughly 5 seconds for a SSD.

That said I did get into some issues recently when using hdparm to erase an SSD which I had connected via the cheapest USB3 caddy I could find on eBay. I’m not sure if it was totally the caddy’s fault or if it was me doing something wrong but anyway, here’s how to wipe a SSD and how to fix the error about bad/missing sense data.

Step 1: Ensure the drive is not frozen and supports secure erase

Once you’ve found the name of the device (/dev/sdb in this case), run the command below to see a load of info about the drive. Towards the bottom is a section about Security. We need it to be not frozen and to support enhanced erase. If your drive is frozen and you’re using a laptop you can try out the unfreeze laptop drive trick which simply involves suspending the laptop with sudo systemctl suspend then waking it up. I’ve found I’ve had to do this if the drive I’m trying to wipe is in the machine’s main SATA port and I’m using a bootable USB to perform the wipe.

roast@mint:~# sudo hdparm -I /dev/sdb

Security:
	Master password revision code = 65534
		supported
	not	enabled
	not	locked
	not	frozen
	not	expired: security count
		supported: enhanced erase

Step 2: Set a new password

Setting a password for the drive will enable the security option so

roast@mint:~# sudo hdparm --user-master u --security-set-pass your-password-here /dev/sdb

If you now run hdparm -I /dev/sdb again you should see the ‘enabled’ option has been activated meaning the drive cannot be used without the password.

Step 3: Perform the secure erase

Final step is to perform the secure erase using your new password:

roast@mint:~# sudo hdparm --user-master u --security-erase your-password-here /dev/sdb

I say it’s the final step but for me this is where shit started to go wrong. I’ve successfully wiped SSDs this way before but this time something freaked out the drive and it refused to behave.

Error: SG_IO: bad/missing sense data

Whenever I tried to perform the secure erase or set the password I got the same error about SG_IO: bad/missing sense data and nothing I did seemed to fix it:

• Tried the magic suspending the laptop trick but that didn’t work.
• Tried the drive in different USB ports but they all did the same.
• Tried another (equally flimsy and low quality) caddy but it did the same thing.
• Tried rebooting the machine.
• Tried removing the drive from the caddy, installing in the laptop, and booting from USB but it refused to show me the boot options menu and instead prompted me for a password for the locked drive. I entered the password but it wasn’t accepted.
• Tried disabling all the hard drives from the boot menu leaving only the USB but it still refused to boot and instead prompted me for the password for the locked drive which wasn’t accepted.

My last resort fixed the error

I had an optical drive to HDD adapter for this machine which allowed me to boot normally and fix the issue:

1. Fitted the drive into an optical to HDD adapter
2. Booted into USB stick (main drive also worked)
3. Ran sudo hdparm -I /dev/sdb which revealed the drive was in fact frozen
4. Did the magic suspending the laptop trick which unfroze the drive
5. Successfully performed the secure erase

Avoid using hdparm with USB to SATA Caddies

I’ve read somewhere that using USB to SATA adapters can cause issues when using hdparm because certain commands don’t get passed through the adapter’s hardware to the SSD properly, and thinking back to all those times I’ve successfully used hdparm I was using a desktop so would have been connecting SSDs directly to the motherboard instead.

The frustrating part of all this was that while the SSD was connected via USB it didn’t show as being frozen. It’s also frustrating (and surprising) that my Thinkpad forced me to boot from a locked drive even after disabling in the bios. And why didn’t the password work? I still have questions to be answered but hey it was a learning experience and it still took way less than 26 hours to figure out.