On 5/5/20 8:39 AM, Qu Wenruo wrote: > > > On 2020/5/5 下午8:36, Jeff Mahoney wrote: >> On 5/5/20 3:55 AM, Johannes Thumshirn wrote: >>> On 04/05/2020 23:59, Richard Weinberger wrote: >>>> Eric already raised doubts, let me ask more directly. >>>> Does the checksum tree really cover all moving parts of BTRFS? >>>> >>>> I'm a little surprised how small your patch is. >>>> Getting all this done for UBIFS was not easy and given that UBIFS is truly >>>> copy-on-write it was still less work than it would be for other filesystems. >>>> >>>> If I understand the checksum tree correctly, the main purpose is protecting >>>> you from flipping bits. >>>> An attacker will perform much more sophisticated attacks. >>> >>> [ Adding Jeff with whom I did the design work ] >>> >>> The checksum tree only covers the file-system payload. But combined with >>> the checksum field, which is the start of every on-disk structure, we >>> have all parts of the filesystem checksummed. >> >> That the checksums were originally intended for bitflip protection isn't >> really relevant. Using a different algorithm doesn't change the >> fundamentals and the disk format was designed to use larger checksums >> than crc32c. The checksum tree covers file data. The contextual >> information is in the metadata describing the disk blocks and all the >> metadata blocks have internal checksums that would also be >> authenticated. The only weak spot is that there has been a historical >> race where a user submits a write using direct i/o and modifies the data >> while in flight. This will cause CRC failures already and that would >> still happen with this. >> >> All that said, the biggest weak spot I see in the design was mentioned >> on LWN: We require the key to mount the file system at all and there's >> no way to have a read-only but still verifiable file system. That's >> worth examining further. > > That can be done easily, with something like ignore_auth mount option to > completely skip hmac csum check (of course, need full RO mount, no log > replay, no way to remount rw), completely rely on bytenr/gen/first_key > and tree-checker to verify the fs. But then you lose even bitflip protection. -Jeff -- Jeff Mahoney SUSE Labs
Attachment:
signature.asc
Description: OpenPGP digital signature
