Okay. Here's my word to whomever may be interested in doing a security-erase on a Kingston SSD from an Ubuntu environment.
Issuing sudo hdparm --user-master u --security-set-pass <password> /dev/sda
as is advised here, among other places (<password> being your chosen password )
will indeed set a user password on your drive.
Note that you must NOT wrap up your password in so-called chevrons (< and >).
If you do that, Terminal will return bash: password: No such file or directory
(password being your chosen password ).
You can confirm that your password has been set by issuing sudo hdparm -I /dev/sda
Security will now have switched from not enabled to enabled,
which according to the aforementioned links would mean it's time to proceed to
sudo hdparm --user-master u --security-erase <password> /dev/sda.
Here is where the trouble began.
security_password: "<password>"
/dev/sda:
Issuing SECURITY_ERASE command, password="<password>", user=user
SECURITY_ERASE: Input/output error
...Terminal replied.
I kept trying, typing my password with or without quotation marks, replacing it with other suggestions such as "", "NULL", or NULL, but Terminal kept giving me the same answer, bottom line being Input/output error
Two days passed and I thought it wise to reboot. Next time I issued sudo hdparm -I /dev/sda
I could see Security had switched not only from not enabled to enabled, but also from not locked to locked.
That's normal. When the password is just set, the drive remains
unlocked until the next power cycle.
Normal as it may be, I got a bit worried, so I decided to try to unlock my drive before doing anything else with it.
From my experience that's impossible.
sudo hdparm --user-master u --security-unlock <password> /dev/sda
returns
security_password: "<password>"
/dev/sda:
Issuing SECURITY_UNLOCK command, password="<password>", user=user
SECURITY_UNLOCK: Input/output error
Wrapping up the password in quotation marks makes no difference.
sudo hdparm --user-master m --security-unlock "" /dev/sda
sudo hdparm --user-master m --security-unlock "NULL" /dev/sda
sudo hdparm --user-master m --security-unlock NULL /dev/sda
or even
sudo hdparm --user-master m --security-unlock " " /dev/sda
(that's 32 spaces)
all return
security_password: "whatever_pw_I_provide"
/dev/sda:
Issuing SECURITY_UNLOCK command, password="whatever_pw_I_provide", user=master
SECURITY_UNLOCK: Input/output error
NOTE that in this case I tried m instead of u, as in master instead of user, having read somewhere (can't find the link at the moment) that setting a user password would set the master password back to NULL; although in Kingston's case it's NULL by default, they say, unless altered by the dealer.
(reference: https://www.kingston.com/datasheets/SVP100ES2_us.pdf)
Anyway, I did try these variants with both m and u, making ZERO progress.
To my surprise came a moment when I said to myself to hell with it and typed
sudo hdparm --user-master m --security-erase "" /dev/sda
Terminal contemplated what I had just said for a while... and BEHOLD, wiped was my drive.
The very same master password ("") that returned the Input/output error for the security-unlock command, worked just fine with the security-erase command.
As mentioned by Tom Yan, there is a bug in hdparm.
Similar issues are reported here:
When I entered NULL as the security it showed up as " " but entering
NULL in the unlock command shows up as "NULL"
Bottom line: Don't lock your ssd unless you really intend to erase it.
PS: Too bad my reputation won't allow me to post more than 2 links.
