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. Thanks, Qu > > -Jeff >
Attachment:
signature.asc
Description: OpenPGP digital signature
