该文章介绍了mathstodon.xyz，一个面向数学爱好者的Mastodon独立服务器，支持LaTeX渲染，由Christian Lawson-Perfect管理，目前有2600名活跃用户。

好的，这是根据您的要求，对原文主要内容进行的中文重述，已保留关键细节并删除了与主题无关的界面元素和对话。

标题：Ingo Blechschmidt 发现并修复了一个长达两年的 Linux 全盘加密安全漏洞

核心内容：

Ingo Blechschmidt 在最近几天经历了一场“有趣、有收获但极其吓人”的调试过程。他发现，自 2024 年 5 月的 Linux 6.9 版本起，一个用于在笔记本挂起时锁定硬盘驱动器的工具一直在静默失效。

这意味着，超过两年的时间里，他和其他使用全盘加密（LUKS）的用户，其加密密钥在笔记本挂起（Suspend）后仍然驻留在内存中。任何拿到这台仍处于通电状态笔记本的人，都可以轻易获取这些密钥。虽然完全关机时加密依然有效，但如今人们很少完全关机。

问题根源：

罪魁祸首是一个看似合理且有用的内核代码重构（相关提交链接），但它与加密代码产生了意想不到的“远距离交互”。修复方法仅需一行代码（补丁链接）。

后续进展与解决方案：

1. 自动化测试：已为 NixOS 添加自动化测试，以防止未来出现类似回归问题（相关PR链接）。
2. 静默失败警告：已提交一个补丁，当此类失败发生时，系统会发出警告而非静默处理（相关MR链接）。
3. cryptsetup 团队响应：cryptsetup 团队的 Ondrej Kozina 迅速跟进，开发了一个能绕过此内核 bug 的补丁，计划在即将发布的 2.8.7 版本中推出（相关MR链接）。同时，Ondrej 在审查补丁时还发现了循环块设备系统中的另一个相关问题，这意味着 Blechschmidt 的单行内核补丁并不完整，仅覆盖了物理块设备上的加密卷，而未覆盖虚拟循环设备。
4. 实验性安全挂起方案：Blechschmidt 发布了一个名为“secure-suspend”的实验性项目（项目链接），专为 NixOS 设计。该项目复活了 Pali Rohár 的一个旧内核补丁，用于在挂起时清除 LUKS 加密密钥。它受 Debian 的 cryptsetup-suspend 启发，但通过内核补丁避免了导致笔记本无法进入睡眠的竞态条件，并增加了额外预防措施。该项目完全支持加密根文件系统。

发现过程：

Blechschmidt 是在整理 Debian 的 cryptsetup-suspend 的 NixOS 移植版时发现此问题的。他查阅 cryptsetup 和内核文档，文档均说明密钥环会附加到调用线程并在线程退出时丢弃，但他却在 /proc/keys 文件中看到了一个本应被清除的密钥条目。最终，他通过 QEMU 虚拟机转储内存，确认了本应被清除的卷密钥仍然存在。

关于安全挂起的讨论：

Blechschmidt 指出，挂起到内存（Suspend to RAM）始终是一种权衡。挂起到加密交换分区（Suspend to encrypted swap）更安全，但更不便。他的项目仅保护 LUKS 加密密钥。他还提到了一个名为 FridgeLock 的项目，该项目可以在挂起前加密大部分内存，但认为复活它可能“有趣且有收获”。

根据评论内容，主要围绕Linux系统休眠时LUKS加密密钥是否安全的问题展开讨论，存在以下核心观点：

观点一：休眠与挂起的安全差异 - 支持者认为挂起（suspend to RAM）时密钥保留在内存中，而休眠（suspend to disk）会清除内存并需要重新输入密码（评论1：bitbasher "When you sleep...the master key is present in kernel memory" / "When you hibernate...the RAM is cleared"） - 评论2（CodesInChaos）补充："I don't have to re-enter my boot password after Sleep, so obviously the encryption key is still in memory"

观点二：安全漏洞的实际风险被夸大 - 评论5（deng）质疑："the laptop is locked when it resumes, how is that key 'for the taking by anyone'?" 认为从锁定设备读取内存并非"任何人"都能做到 - 评论6（kokada）指出该问题仅影响Debian的扩展功能："this cryptsetup luksSuspend...is not really officially supported but an extension done in Debian"，认为标题有标题党嫌疑

观点三：休眠是更彻底的防护方案 - 评论7（fpoling）建议："I just configured Linux to hibernate to disk after 15 minutes of suspend" 并强调"hibernating is really the only proper way to protect against cold boot"

观点四：对Linux系统复杂性的反思 - 评论3（naturalmovement）讽刺："Definitely not a symptom of Linux being a hodgepodge of code thrown together from a thousand different sources" - 评论4（johnathan101）指出安全漏洞的隐蔽性："Security bugs often don't announce themselves"

平衡性总结：评论呈现了技术细节（休眠vs挂起）、风险认知差异（实际威胁程度）、解决方案建议（休眠策略）以及对Linux生态的批评。多数评论认可该漏洞存在，但对其实际影响范围和严重性存在分歧。