Eu não sei se isso realmente está respondendo a pergunta que você queria.
No entanto, usei informações nesta página:
link
Eu tinha um SSD auto-criptografado. Eu usei o comando hdparm para definir uma senha de usuário, uma senha mestra e definir o recurso de senha mestra como "máximo", para que uma senha mestra não possa ser desbloqueada ou desativada, apenas apague. (Minha BIOS não me deixou definir uma senha mestra ou o modo mestre. Isso é realmente inseguro, pois a manufatura (Dell) tem a senha mestra e, provavelmente, qualquer representante de serviço pode obtê-la.)
Um bom BIOS / UEFI deve desbloquear o driver e congelá-lo para que a senha não possa ser desabilitada pelo sistema operacional. Se o firmware deixar a unidade descongelada, poderei ver como a senha pode ser desativada.
No entanto, tudo isso pressupõe que você confie no firmware da unidade para não ter um backdoor ou falha de segurança. O artigo que você cita parece implicar que isso é comum. Eu questiono o quão "fácil" é o nível de bios para derrotar como o artigo afirma que a unidade já deve estar desbloqueada. O artigo não dizia se a segurança da unidade estava congelada ou não.
Se você não confiar no firmware das unidades, não vejo como qualquer funcionalidade de senha do ATA pode ajudá-lo. Para ainda se beneficiar da unidade HW, você precisaria acessar o próprio mecanismo AES e ser capaz de programar a tecla AES sozinho.
era: {não conheço essa API de nível de HW. Eu estaria interessado se alguém tiver uma referência.}
Desculpe, eu deveria ter lido todas as suas referências antes de responder. Os padrões em questão são o TCG Opal 2.0 e o IEEE-1667. Parece que 1667 move para um protocolo de resposta do desafio sobre a troca de senha de texto simples do ATA. No entanto, parece-me que as senhas ainda estão armazenadas na unidade e você ainda precisa confiar no firmware da unidade.