LUKS 加密中的位旋转

Question

位腐烂如何影响 LUKS 容器及其内部文件系统？

假设您有一个非常适合处理位腐烂的文件系统。现在将其放入 LUKS 容器中。如果位腐烂损坏了容器，我假设解密的文件系统将遭受大量损坏的原始字节/块。

LUKS 如何防范这种情况？

Answer 1

LUKS 标头中的 Bitrot（关键和其他关键材料）：它*噗*消失了。

（LUKS2 标头有一些冗余和校验和，但它涵盖的内容不多，所以很可能......它仍然消失了）。

加密数据中的Bitrot：取决于加密模式，但一般情况下，单个位翻转会导致16个错误字节。

设置加密：

# truncate -s 32M bitrottest.img
# cryptsetup luksFormat bitrottest.img
# cryptsetup luksOpen bitrottest.img bitrottest

使其全部为零：

# shred -n 0 -z /dev/mapper/bitrottest 
# hexdump -C /dev/mapper/bitrottest 
00000000  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
01000000

稍微翻转一下：

# losetup
NAME       SIZELIMIT OFFSET AUTOCLEAR RO BACK-FILE           DIO LOG-SEC
/dev/loop0         0      0         1  0 bitrottest.img        0    4096
# dd bs=1 count=1 skip=30M if=/dev/loop0 | hexdump -C
00000000  a2                                                |.|
00000001
# printf "\xa3" | dd bs=1 count=1 seek=30M of=/dev/loop0
# dd bs=1 count=1 skip=30M if=/dev/loop0 | hexdump -C
00000000  a3                                                |.|
00000001

结果：

# hexdump -C /dev/mapper/bitrottest 
00000000  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
00e00000  eb d1 bd b0 2a f5 77 73  35 df 82 40 1e a7 27 11  |....*.ws5..@..'.|
00e00010  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
01000000

一位翻转位，16 个奇怪的字节。

保护？没有任何。为此，您必须添加完整性（只是为了报告错误，冗余仍然是一个单独的问题）。

您不应该故意将损坏的数据写入您的存储。

存储应该报告读取错误而不是返回虚假数据。在这种情况下，您的数据仍然消失了，但至少，它不是无声的比特腐烂。

Answer 2

LUKS 本身并不能防止位腐烂。如果您希望在块设备级别上防止位损坏，则需要DM 完整性。LUKS 2 可以与完整性相结合以获得经过身份验证的加密（cryptsetup luksFormat使用--integrity），并且使用该系统将能够检测到数据已更改，但这对于防止位腐烂并没有真正的帮助 - 如果您这样做，该扇区只会给您 IO 错误尝试阅读它，但不知道如何解决它。（AEAD 的目的是检测有人更改了加密数据。）

要实际修复数据，您需要 RAID 1 和 RAID 支线下的独立完整性设备，以使自我修复成为可能（这会自动工作，RAID 从一条支线获取 IO 错误，从另一支线读取数据并修复（尝试） 第一个）。新的systemd 250添加了对在引导期间组装完整性设备的支持/etc/integritytab（对于非根文件系统），因此您可以尝试一下。但这一切都需要在 LUKS 级别“下”完成，才能使其像 @frostschutz 在他的答案中所示的那样工作，因为需要在加密数据中修复错误。