自 Linux 核心 6.9 起，LUKS 暫停流程不再從記憶體清除磁碟加密金鑰 （★ 109 分）
這則 Mastodon 貼文指向一個 Linux 磁碟加密的安全退化：自 Linux 核心 6.9 起，LUKS (Linux Unified Key Setup，Linux 常見磁碟加密規格) 的暫停流程不再如預期把磁碟加密金鑰從記憶體中清除。作者補充說，Debian 曾提供選用的 cryptsetup-suspend 附加工具，會在系統進入睡眠時呼叫 luksSuspend，理應清除核心記憶體中的 master key（主金鑰），並在恢復時要求使用者重新輸入密語；這個流程在 Linux 6.8 以前正常，從 6.9 開始則悄悄失效。
原始 Mastodon 快取頁只顯示需啟用 JavaScript 才能使用網頁應用程式；技術脈絡主要來自作者在後續討論中的說明。討論指出，多數一般 Linux 發行版在 suspend-to-RAM（暫停到 RAM，讓記憶體持續供電以快速恢復）時，本來就會保留整個 RAM 狀態，包含核心中的磁碟加密主金鑰。因此，如果筆電從睡眠喚醒後不需要重新輸入開機解密密語，通常就表示金鑰仍留在記憶體裡；cryptsetup-suspend 的特殊價值正在於讓睡眠模式也能更接近「清除金鑰後再恢復」的安全語意。
留言者也區分 sleep 與 hibernate（休眠到磁碟）：前者保留 RAM 供電，可能讓冷開機攻擊或實體記憶體攻擊有機會取得殘留金鑰；後者會把 RAM 映像寫入磁碟並關閉電源，在磁碟加密與休眠流程設定正確時，恢復需先解密休眠映像。討論也延伸到 Windows 的對照，有人指出 VeraCrypt 並非企業 Windows 環境的主流磁碟加密方案，BitLocker（Microsoft 內建磁碟加密）才更常見，顯示不同平台對睡眠、休眠與金鑰管理的預設安全假設並不相同。
更廣泛的爭論集中在 Linux 生態的複雜性。一些留言把這起退化歸因於 Linux 由核心、systemd、發行版工具與不同版本組合而成，責任邊界容易模糊；其他人反駁說，任何大型作業系統都會因長期演進與多人維護而累積複雜度，BSD、macOS 或 Windows 若達到同等規模也會面臨類似問題。開放原始碼一方的觀點是，這類安全缺陷至少能被外界檢視與修補；相對地，封閉原始碼系統的錯誤與潛在後門較難由使用者獨立驗證。
👥 23 則討論、評論 💬
https://news.ycombinator.com/item?id=48763035