Linux 核心回歸：LUKS 加密金鑰在掛起時未被清除

在 Linux 6.9（2024 年 5 月）中引入的一個回歸，使得 LUKS 磁碟加密金鑰在 suspend‑to‑RAM（掛起至記憶體）期間仍保留在記憶體中，實際上關閉了本應清除這些金鑰的安全機制。此漏洞使得加密資料在筆記型電腦於掛起狀態下被查獲時，可能透過冷開機攻擊或其他記憶體轉儲技術被竊取。

根本原因：一次沉默的重構失敗

原本預期在執行緒退出時會丟棄加密金鑰，但核心對區塊裝置存取的重構導致金鑰清除工具靜默失效。問題被追溯到一個將區塊裝置存取移植到檔案的特定核心提交，該提交與加密程式碼產生了意外的長距離交互作用。

由於系統仍能正常運作——筆記型電腦仍能順利掛起與復原且不會出錯——此回歸在兩年多的時間裡未被發現。正如社群成員所指出的，這類安全漏洞往往不會自行顯現，因為它們不會導致系統崩潰或功能失效。

偵測與緩解

此漏洞由 Ingo Blechschmidt 透過源碼分析與記憶體取證的結合發現。當他嘗試將受 Debian 啟發的 cryptsetup-suspend 工具整合到 NixOS 時，注意到即使文件說明金鑰應已被丟棄，/proc/keys 中的條目仍然可見。他在 QEMU 中執行虛擬機並轉儲記憶體，確認了金鑰仍留在 RAM 中。

目前的修補與變通方案

• 核心修補程式：開發了一行程式碼的核心修補，解決了實體區塊裝置上加密卷的常見情況。然而，後來發現此修補不完整，因為它未涵蓋虛擬迴環裝置。
• Cryptsetup 更新：cryptsetup 團隊的 Ondrej Kozina 提供了一個繞過核心漏洞的變通方案。此修補預計在 cryptsetup 2.8.7 版中發布。
• NixOS 實作：NixOS 已發布一個實驗性的「安全 suspend‑to‑RAM」專案，該專案復活了 Pali Rohár 先前的核心修補，以在掛起時清除 LUKS 金鑰。
• 替代電源狀態：關注此漏洞的使用者可以改用 suspend‑to‑disk（休眠）。與 suspend‑to‑RAM 不同，休眠會將 RAM 內容寫入加密的 swap 分割區，並關閉記憶體電源，確保金鑰不會以明文留在 RAM 中。

威脅模型與技術背景

此修補主要針對 冷開機攻擊（cold boot attack），即攻擊者在取得實體存取權且機器處於開機但掛起狀態時，轉儲 RAM 內容以恢復加密金鑰。

社群對記憶體安全的看法

關於此 bug 的技術討論突顯了多層防禦策略：

"如果你的 CPU 支援，請啟用記憶體加密……沒有明文會離開 CPU 封裝。DIMM 交換攻擊將變得毫無用處。"

其他使用者建議利用 TPM 功能，例如 MemoryOverwriteRequestControl，以確保開機時記憶體被清除。也有人討論此 bug 的範圍；有觀點認為因為 cryptsetup luksSuspend 主要是 Debian 的特定擴充，而非上游 Linux 的核心功能，影響僅限於特定發行版。

修復彙總

方法	安全等級	便利性
Suspend‑to‑RAM（未修補）	低（金鑰仍在 RAM）	高
Suspend‑to‑RAM（已修補）	中（金鑰已清除）	高
Hibernate（Suspend‑to‑Disk）	高（RAM 已斷電）	中
硬體記憶體加密	非常高	高