如果计算机关闭，数据可以在 RAM 内存中保留一段时间；衰减约 5 分钟。这可以通过冷却芯片来延长：
https://citp.princeton.edu/research/memory/media/
这使得对加密密钥进行冷启动攻击成为可能。
有TRESOR其存储密钥内部CPU寄存器，而不是在RAM中。
尽管如果人们将 FDE 与 ex.: LUKS 一起使用，“RAM 中的明文密码/密钥”可能仍然是一个问题。
TRESOR 或类似 TRESOR 的解决方案能否解决这些问题（？）还是会引入新问题？
问题：这种方法（加密 RAM 并将密钥存储在 CPU 中？）是否集成在 Linux 内核中？还是默认情况下未启用？
不，TRESOR 从未集成到 Linux 内核中。它特定于 x86 架构，并且需要 AES-NI 才能避免产生非常讨厌的开销。由于存储密钥的 DR 寄存器的大小有限，它无法存储和预计算轮密钥（常见的 AES 优化），因此必须每次重新计算它们。如果你有 AES-NI，这不是什么大问题，但如果你没有，这可能会很痛苦。Linux 开发人员不喜欢在针对硬件错误的特定取证技术中添加一个变通的变通方法，尤其是当缓解措施仅适用于具有 AES-NI 的较新 x86 CPU 时。
此外，它还可以防止设置硬件断点。现在，人们通常在调试时设置软件断点，因为一次最多只能设置4个硬件断点，但有些人因为性能较低而不能使用软件断点。TRESOR，因为它使用所有的 DR 寄存器，所以要求内核告诉用户空间 DR 寄存器的数量为 0，并出于安全原因阻止对它们的所有访问。
关于它是否解决了冷启动攻击的问题，答案是部分的。它完全缓解了从内存中窃取加密密钥的问题，但它不会加密其余的内存。如果你打开一个超级机密文件，它会在你的页面缓存中停留一段时间。如果您的系统当时是冷启动的，那么您的大部分磁盘以及您的 AES 密钥可能会受到保护，但缓存中的所有文件（包括该超级机密文件）都会暴露出来。RAM 中的其他数据也是如此，例如在 Web 浏览器中打开的页面等。