位腐烂如何影响 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 在他的答案中所示的那样工作,因为需要在加密数据中修复错误。