自 Linux 6.9 起，LUKS 挂起不再会从内存中擦除磁盘加密密钥

回归的性质

• 自 Linux 6.9 起，cryptsetup luksSuspend 在挂起时不再能可靠地从 RAM 中擦除 LUKS 卷密钥，尽管用户在恢复时仍会被提示输入口令。
• 该 bug 源于内核 keyring 生命周期的变化：存放在线程 keyring 中的密钥原本预期会在线程退出时消失，但后来不再这样，导致卷密钥在内核内存中留下了一份额外副本。
• 这使得那些以为自己在“挂起时额外安全”的系统，安全性低于预期，但表面上看起来仍然正常工作。

挂起 vs 休眠，以及威胁模型

• 挂起到 RAM：RAM（包括磁盘密钥）仍然通电；大多数系统不会清除 LUKS 密钥，因此磁盘加密主要保护的是断电或被移除的磁盘。
• 休眠到磁盘：RAM 内容（包括密钥）会写入加密的 swap/镜像中，RAM 断电；恢复时，用户需要重新输入口令。
• 有人认为只有休眠（或始终关机）才能真正抵御冷启动攻击；也有人指出，攻击的现实可行性高度依赖威胁模型。

冷启动与物理访问

• 若攻击者能物理接触到一台处于挂起且已锁定的笔记本，他们可以：
  • 执行冷启动攻击（快速重启进入自定义 OS，或冻结并转移 RAM）。
  • 在配置不佳的系统上使用 DMA 或类似技术。
• 多条评论强调，这主要与高价值目标或国家级目标有关，而不是普通盗贼。

变通方法与缓解措施

• 讨论中提到的推荐缓解措施：
  • 用休眠替代挂起；一些 Fedora 用户会在挂起超时后自动休眠。
  • 在可用时启用 CPU 内存加密（Intel/AMD 功能），不过这主要针对物理 RAM 攻击，而不是密钥被逻辑滥用。
  • 使用 EFI/TPM 功能，例如 MemoryOverwriteRequest，以确保重启时 RAM 被擦除。

范围与发行版细节

• luksSuspend 是 cryptsetup 的上游功能；Debian 增加了将其与挂起联动的集成，据称这种做法已被移植到其他发行版。
• 这一回归影响的是依赖 luksSuspend 语义的配置，而不是标准的“直接挂起”设置。

对比与更广泛的安全主题

• 有一段较长的讨论比较了 BitLocker、FileVault、LUKS 和 VeraCrypt：
  • 企业更喜欢 BitLocker 的可管理性，尤其是 TPM+PIN 和密钥托管。
  • 注重隐私的用户对专有加密和云端密钥托管持谨慎态度。
• 多条评论强调：
  • 开源更容易审计，但并不意味着自动就会被审计。
  • 缺乏健壮的集成测试让这次回归得以发生；增加专门测试被视为真正的长期修复。