我已将 GRUB2 安装到加密的启动分区，详见这里。我选择的哈希算法luksFormat是sha512，使用默认值iter-time（2 秒）。
如果从命令行（从阿奇索或从正在运行的系统），但 GRUB 平均需要 10.5 秒来解锁它。对于我的场景来说，这比可接受的要慢。
我发现其他人也有同样的问题这里和这里。在第二个链接中，用户弗罗斯特舒茨已经发布了一些关于可能导致此问题的提示，我认为其中 2 条非常有效：
1) 早期GRUB解锁期间CPU可能运行在省电模式下
2) GRUB 可能使用比系统慢得多的哈希实现。他做了一个基准测试可以发现这里。
由于加密启动分区似乎变得越来越普遍，而且这个问题还没有令人满意的答案，我想我应该问一下这个问题。除了减少迭代次数（这会大大降低离线攻击场景中的安全性）之外，还能做什么来应对 GRUB 引导加载程序的这种（慢得多）解密时间？
我想至少查明确切的原因。有没有办法在引导加载程序屏幕中检查（并可能更改）CPU 时钟？我知道 GRUB 有一个 shell；我打开它并尝试，cat /proc/cpuinfo但失败并显示“/proc not found”或类似的内容。我也尝试过cpuid，虽然它没有失败，但也没有返回任何内容。
作为附加信息，我得到了这些时间：
- GRUB 需要9秒或更长时间
/boot输入密码并按 后解锁启动分区 ( ) Enter。 - 内核似乎需要大约 7 秒来解锁根分区 (
/)。同样，这是在按下 后计时的Enter。 - 内核
/boot通过以下方式解锁并挂载启动分区 ( )crypttab仅需2秒多一点。
更新：
我尝试了 SHA256 哈希，但花费了更长的时间（13 秒）。这可能表明 GRUB 必须使用 64 位，这可以从这里,https://security.stackexchange.com/a/40218/91904并在霜舒兹的回答。
还尝试了 SHA1，需要 11.5 秒。
使用 AES256 还是 AES512 似乎没有什么区别
启动分区使用哪个文件系统也并不重要。
答案1
GRUB 是早期引导。还没有可用的操作系统，也没有 Linux，尽管我们往往会忘记这一点，因为 GRUB 本身就可以完成许多令人惊奇和疯狂的事情。所以一条/proc not found消息并不奇怪。
SHA512 从 64 位指令中受益匪浅，但 GRUB 可能还无法使用这些指令。尝试 SHA256 或 SHA1，也许它们更适合 GRUB。您在 LUKS 中使用哪种哈希规范并不重要，因为 iter 计数只会相应地进行调整。看如何更改现有 dm-crypt LUKS 设备的哈希规范和迭代时间？关于如何尝试不重新加密所有内容。
GRUB 似乎正在使用 gcrypt 库的某些变体来满足其散列需求。我不知道是否我很旧的基准仍然有效。当我测试它时，它不是最快的库（至少是使用它的方式cryptsetup benchmark）并且存在令人惊讶的巨大差异。
因此，如果您没有将 gcrypt 与 cryptsetup 二进制文件一起使用，这可能是解锁时间差异的另一个原因。也许您只需要进行试验，直到找到适合您的值。
随着加密启动分区似乎变得越来越普遍，
由于所有错误的原因......人们篡改你的 /boot，人们同样容易篡改你的引导加载程序。 GRUB 只支持最直接的方案，如果落到一个廉价的键盘记录器手中还有什么意义呢？