Mar*_*377 10 performance boot-loader encryption grub2
我已将 GRUB2 安装到加密的引导分区，详情请见此处。我选择的散列算法luksFormat是sha512，默认值iter-time（2 秒）。
如果从命令行（从archiso或从正在运行的系统）解锁，这个加密分区需要 2 秒多一点的时间，但 GRUB 平均需要 10.5 秒来解锁它。对于我的场景，这比可接受的要慢。
我发现其他人在这里和这里有同样的问题。在第二个链接中，用户frostschutz发布了一些关于可能导致这种情况的提示，我认为其中 2 条非常有效：
1) 早期 GRUB 解锁期间 CPU 可能处于省电模式
2) GRUB 可能正在使用比系统慢得多的散列实现。他做了一个基准测试，可以在这里找到。
由于加密启动分区似乎变得越来越普遍，而且这个问题还没有令人满意的答案，我想我会问这个问题。除了减少迭代次数（这会大大降低离线攻击场景中的安全性）之外，还可以做些什么来应对 GRUB 引导加载程序的（慢得多）解密时间？
我想至少查明确切原因。有没有办法在引导加载程序屏幕中检查（并可能改变）CPU 时钟？我知道 GRUB 有一个外壳；我打开它并尝试过cat /proc/cpuinfo但它失败了“/proc not found”或类似的东西。我也试过cpuid，虽然它没有失败，但它也不返回任何内容。
作为附加信息，我得到了这些时间：
/boot) Enter。/)。同样，这是按 后计时的Enter。/boot) crypttab。更新：
我尝试了 SHA256 散列，但花费了更长的时间（13 秒）。这可能表明 GRUB 必须使用 64 位，从这里可以推断出，https: //security.stackexchange.com/a/40218/91904和frostschutz 的回答。
还尝试了 SHA1，它需要 11.5 秒。
使用 AES256 还是 AES512 似乎没有区别
引导分区使用哪个文件系统也无关紧要。
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 只支持最直接的方案，如果落到一个廉价的键盘记录器手中还有什么意义呢？