No sé si esto realmente responde la pregunta que querías. Sin embargo, he usado información en esta página:
https://ata.wiki.kernel.org/index.php/ATA_Secure_Erase
Tuve un SSD auto cifrado. Utilicé el comando hdparm para establecer una contraseña de usuario, una contraseña maestra, y establecer la capacidad de contraseña maestra en "máximo" para que una contraseña maestra no se pueda desbloquear o deshabilitar, solo borrar. (Mi BIOS no me permitió establecer una contraseña maestra o el modo maestro. Esto es realmente inseguro ya que el fabricante (Dell) tiene la contraseña maestra y probablemente cualquier representante de servicio pueda obtenerla).
Un buen BIOS / UEFI debe desbloquear el controlador y congelarlo para que el sistema operativo no pueda deshabilitar la contraseña. Si el firmware deja la unidad sin congelar, podría ver cómo se puede deshabilitar la contraseña.
Sin embargo, todo esto supone que confía en que el firmware de las unidades no tenga una puerta trasera o un agujero de seguridad. El artículo que cita parece implicar que esto es común. Cuestiono cuán "fácil" es derrotar el nivel de BIOS ya que el artículo establece que la unidad ya debe estar desbloqueada. El artículo no decía si la seguridad de la unidad estaba congelada o no.
Si no confía en el firmware de las unidades, entonces no veo cómo ninguna de las funciones de contraseña de ATA puede ayudarlo. Para seguir beneficiándose de la unidad HW, necesitaría acceso al motor AES y poder programar la llave AES usted mismo.
fue: {No conozco una API de nivel HW de este tipo. Me interesaría si alguien tiene una referencia.}
Lo siento, debería haber leído todas sus referencias antes de responder. Los estándares en cuestión son TCG Opal 2.0 e IEEE-1667. Parece que 1667 pasa a un protocolo de respuesta de desafío sobre el intercambio de contraseña de texto claro de ATA. Sin embargo, me parece que las contraseñas todavía están almacenadas en la unidad y que aún debería confiar en el firmware de la unidad.