目标：（大部分）具有多个卷的全盘加密，其中一些是独立加密的
理由：加密将保护未启动的磁盘，但对于 24/7 的系统来说，它在适当的情况下并不能提供太多的安全性。此外，即使授权用户不需要某些数据，也希望保持其卸载和安全。
可能的解决方案：
LVM 上的多个 LUKS
- 缺点：应该可行，但通常不明智且复杂。
LUKS 上的 LVM + LUKS 上带有 LVM 的单独分区
- 缺点：拥有分区会降低 LVM 灵活性的优势。
LUKS 上的 LVM，其中某些卷为 LVM-on-LUKS-on-LVM-on-LUKS，即双重加密
- 缺点：双重加密可能会影响性能。而且，复杂/令人费解。但保持了LVM的灵活性。
这些选项中哪一个可能是最好的？
双重加密会造成多少性能损失？hdparm -t结果显示，在我的 SATA SSD 上，未加密、加密或双重加密卷之间的磁盘读取没有任何差异。
还有其他解决方案吗？
答案1
很难回答，因为主要基于意见。您不妨问哪个更好，LVM on LUKS 还是 LUKS on LVM。无论哪种方式都有效，并且可能更适合您的特定要求。
对于独立的 LUKS 容器，LVM -> LUKS 听起来肯定比 LUKS -> LVM 更有趣，但代价是 LVM 元数据未加密 - 并且逻辑卷名称、大小、创建时间等可能会泄露信息。
双重加密肯定会带来性能损失（即使使用 AES-NI）。然而，在某些用例中这仍然没问题。也许您的 CPU 非常空闲（在超强大的桌面系统上并不罕见），因此您没有注意到任何差异，或者您的双重加密数据可能对性能并不重要。
我可能最终会这样做，我已经有了 LUKS -> LVM，所以如果我需要另一个加密层，那就是 LUKS -> LVM -> LUKS ，因为这样做更容易、更安全（只需制作另一个 LV 并放入 LUKS ）而不是说，缩小 PV 来为独立的 LUKS 分区腾出空间（当执行这些特技时，事情可能会出错）。
但是，我不会在其上放置另一个 LVM 层，因为我不太明白 LVM 内部的 LVM 的意义。所以对我来说，LUKS -> LVM -> LUKS 就结束了。
理论上，无需双重加密即可进行双重加密设置，即设备映射器可以允许内部 LUKS 容器将其数据直接传递到外部设备，而无需对其进行两次加密。设备映射器应该足够强大来实现这一点，但 LVM 和 cryptsetup 几乎肯定不会支持这样的事情。