LUKS 加密中的位旋转

LUKS 加密中的位旋转

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

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

LUKS 如何防范这种情况?

答案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 个奇怪的字节。

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

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

存储应该报告读取错误而不是返回虚假数据。在这种情况下,您的数据仍然消失了,但至少,它没有消失沉默的位旋转。

答案2

LUKS 本身并不能防止位腐烂。如果您想在块设备级别上防止位腐烂,您需要DM 完整性。 LUKS 2 可以与诚信结合得到认证加密cryptsetup luksFormat使用--integrity)并且使用该系统将能够检测到数据已更改,但这对于防止位腐烂并没有真正的帮助 - 如果您尝试读取它并且不知道如何读取,该扇区只会给您 IO 错误修理它。 (AEAD 的目的是检测有人更改了加密数据。)

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

相关内容