根据我的阅读，有两种已知的使用自加密驱动器 (SED) 的方法：
hdparm
https://www.pugetsystems.com/labs/articles/Introduction-to-Self-Encrypting-Drives-SED-557/
sedutils
https://github.com/Drive-Trust-Alliance/sedutil/wiki/Encrypting-your-drive
然而，在阅读了有关每种方法的信息后，我仍然不确定以下内容：
这些方法是同一件事的两种选择吗？我可以同时使用两者吗？ （例如使用一进行锁定，使用二进行解锁）
这两种方法的主要区别是不是
hdparm需要BIOS ATA密码功能，而不sedutils需要呢？这是否意味着 sedutils 是与 SED 驱动器一起使用的首选方式，因为它不需要 BIOS 支持的 ATA 密码？
答案1
在这方面SED= 自加密磁盘
sedutil那个软件包是应该使事情在Linux中工作据我所知。所以我不会使用高清参数除了验证和诊断之外。
Drive Trust Alliance 软件 (sedutil) 是开源软件 (GPLv3)努力使每个人都可以免费使用自加密驱动器技术。它是当今两个已知可用的开源代码库的组合：msed 和 OpalTool。
购买了很多之后自加密来自知名硬盘制造商的 SSD，通过电子邮件发送给他们，并通过电子邮件向 LSI/Avago/Broadcom 发送关于能够进行 SED“加密”的 sas raid 控制器，以及具有 TPM 的知名服务器主板制造商，我我发现这个自加密更像是一种广告和营销策略，在我看来，如果人们只是将这些插入并认为因为他们是“自我加密”而这一切就发生了，那么值得集体诉讼我不会感到惊讶；它不是！
- 关于如何使其工作的说明几乎不存在
根据您的 pugetsystem 链接：当我们决定开始在我们的系统上提供 SED 加密时，我们发现对 SED 的全面支持实际上非常差。有很多硬盘和 SSD 型号支持 SED 加密（尽管找到这些型号可能很困难），但完全支持 SED 还需要兼容的主板。
在给主板、raid 控制器和硬盘制造商发送电子邮件后，人们会认为我会有一些合理的解决方案。不。
作为一个最终用户我认为需要主板的“完全支持”才能与SATA/SAS控制器连接以启用或导致自加密即将发生。此加密不同于 SATA/SAS 控制器级别的“驱动器锁定”（因为磁盘上或磁盘中的数据未加密）。
- 我找到的最好的资料是来自希捷 1200.2 固态硬盘的产品文档，其中引用了驱动器加密，但是我还没有在我的固态硬盘上实现“自加密”。从我收集的文档来看，它可以归结为发生的 2 个 scsi 命令：安全协议输出和安全协议。这是怎么发生的，我还不知道。
- 最有可能的解决方案似乎是sedutil在 Linux 中打包并以某种方式使用命令行界面sedutil-cli。据我所知，这一切都来自 Linux 操作系统内部。
- 我对 SED 的最初回应都是基于 Microsoft Windows 的；当然，SED 似乎仍处于开发阶段，尚未准备好在黄金时间使用（这并不容易，人们不应该在现有指令中描述的级别上执行 cli 或 hdparm 命令）。不过，我毫不怀疑 SED 确实能够在其内部进行加密，但默认情况下它不会发生，这就是问题所在。
答案2
hdparm可以设置密码并使用密码解锁驱动器，但它是一个用户空间应用程序。这意味着它只能在您启动系统后运行。如果您想加密启动驱动器，那么hdparm将没有帮助。此外，我相信它hdparm仅适用于 SATA/IDE 设备，不适用于 NVMe 存储设备。
sedutil安装在启动过程中运行的 UEFI 应用程序，并允许您输入密码、解密驱动器，然后继续从其启动。