Ok. Aqui está minha palavra para quem estiver interessado em fazer um apagamento de segurança em um SSD da Kingston a partir de um ambiente Ubuntu.
Emitindo sudo hdparm --user-master u --security-set-pass <password> /dev/sda
Como é aconselhado aqui , entre outros lugares ( <password> sendo a sua senha escolhida) de fato irá definir uma senha de usuário em sua unidade.
Observe que você NÃO deve finalizar sua senha nas chamadas divisas ( < e > ).
Se você fizer isso, o Terminal retornará bash: password: No such file or directory
( password sendo seu senha escolhida).
Você pode confirmar que sua senha foi definida emitindo sudo hdparm -I /dev/sda
Segurança agora terá comutado de não ativado para ativado ,
que, de acordo com os links acima, significa que é hora de prosseguir para sudo hdparm --user-master u --security-erase <password> /dev/sda .
Aqui é onde o problema começou.
security_password: "<password>"
/dev/sda:
Issuing SECURITY_ERASE command, password="<password>", user=user
SECURITY_ERASE: Input/output error
... Terminal respondeu.
Eu continuei tentando digitar minha senha com ou sem aspas, substituindo-a por outras sugestões como "" , "NULL" ou NULL , mas o Terminal continuou me dando a mesma resposta, sendo a linha de base Input/output error
Dois dias se passaram e achei melhor reiniciar. Da próxima vez que eu emiti sudo hdparm -I /dev/sda
Pude ver que Segurança mudou não apenas de não habilitado para ativado , mas também de não bloqueado para > bloqueado .
That's normal. When the password is just set, the drive remains
unlocked until the next power cycle.
Por mais normal que seja, fiquei um pouco preocupado, então decidi tentar desbloquear o disco antes de fazer qualquer outra coisa.
Da minha experiência, isso é impossível.
sudo hdparm --user-master u --security-unlock <password> /dev/sda
retorna
security_password: "<password>"
/dev/sda:
Issuing SECURITY_UNLOCK command, password="<password>", user=user
SECURITY_UNLOCK: Input/output error
Resolver a senha entre aspas não faz diferença.
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
ou até mesmo
sudo hdparm --user-master m --security-unlock " " /dev/sda
(são 32 espaços)
todo retorno
security_password: "whatever_pw_I_provide"
/dev/sda:
Issuing SECURITY_UNLOCK command, password="whatever_pw_I_provide", user=master
SECURITY_UNLOCK: Input/output error
OBSERVE que, neste caso, tentei m em vez de u , como em master em vez de usuário , tendo lido em algum lugar (não pode encontrar o link no momento) que definir uma senha de usuário deve definir a senha mestra de volta para NULL; embora no caso de Kingston seja NULL por padrão, eles dizem, a menos que seja alterado pelo revendedor.
(reference: https://www.kingston.com/datasheets/SVP100ES2_us.pdf)
De qualquer forma, eu experimentei essas variantes com m e u , fazendo o progresso ZERO.
Para minha surpresa veio um momento em que eu disse a mim mesmo para o inferno com ele e digitei sudo hdparm --user-master m --security-erase "" /dev/sda
Terminal contemplou o que eu tinha acabado de dizer por um tempo ... e BEHOLD, apagado foi o meu impulso.
A mesma senha mestra ( "" ) que retornou o Input/output error para o comando security-unlock funcionou muito bem com o comando security-erase .
Como mencionado por Tom Yan, há um bug em hdparm .
Questões semelhantes são relatadas aqui :
When I entered NULL as the security it showed up as " " but entering
NULL in the unlock command shows up as "NULL"
Conclusão: não bloqueie seu ssd, a menos que você realmente pretenda apagá-lo.
PS: É uma pena que minha reputação não permita que eu poste mais de 2 links.