GRUB 解鎖加密引導分區的時間過長
我已將 GRUB2 安裝到加密的引導分區，詳見此處。為 my 選擇的散列算法
luksFormat是sha512，預設值iter-time（即 2 秒）。如果從命令行（從archiso或正在執行的系統）完成，這個加密分區需要 2 秒多一點的時間來解鎖，但 GRUB 平均需要 10.5 秒來解鎖它。這比我的場景可以接受的要慢。
我發現其他人在這里和這裡有同樣的問題。在第二個連結中，使用者frostschutz發布了一些可能導致此問題的提示，我認為其中 2 個非常有效：
早期 GRUB 解鎖期間 CPU 可能在省電模式下執行
GRUB 可能正在使用比系統慢得多的散列實現。他做了一個可以在這裡找到的基準。
由於加密引導分區似乎變得越來越普遍，並且這個問題還沒有令人滿意的答案，我想我會問這個問題。除了減少迭代次數（這會大大降低離線攻擊場景中的安全性）之外，還能做些什麼來應對 GRUB 引導載入程序的這種（大大）較慢的解密時間？
我想至少查明確切的原因。有沒有辦法在引導載入程序螢幕中檢查（並可能更改）CPU 時鐘？我知道 GRUB 有一個外殼。我打開它並嘗試過
cat /proc/cpuinfo，但它失敗了“/proc not found”或類似的東西。我也試過cpuid了，雖然它沒有失敗，但它也沒有返回任何東西。作為附加資訊，我得到了這些時間：
- 輸入密碼並按 後，GRUB 需要9 秒或更長時間才能解鎖引導分區 ( ) 。
/boot``Enter- 核心似乎需要大約 7 秒才能解鎖根分區 (
/)。同樣，這是在按下 後計時Enter。- 核心通過2 秒多一點的時間解鎖並掛載引導分區 (
/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 一起使用的雜湊規範無關緊要，因為迭代計數將相應地進行調整。請參閱如何更改現有 dm-crypt LUKS 設備的雜湊規範和迭代時間？關於如何嘗試不重新加密所有內容。
GRUB 似乎正在使用 gcrypt 庫的某些變體來滿足其散列需求。我不知道我的舊基準是否仍然有效。當我測試它的時候，它並不是最快的庫（至少是它使用的方式
cryptsetup benchmark），並且存在驚人的巨大差異。因此，如果您沒有在 cryptsetup 二進製文件中使用 gcrypt，這可能是解鎖時間不同的另一個原因。也許您只需要進行試驗，直到找到適合您的值。
隨著加密引導分區似乎變得越來越普遍，
由於所有錯誤的原因……人們篡改了您的 /boot，人們同樣容易地篡改了您的引導載入程序。GRUB 只支持最直接的方案，如果它落到一個便宜的鍵盤記錄器上，那有什麼意義呢？