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. -Jeff -- Jeff Mahoney SUSE Labs
Attachment:
signature.asc
Description: OpenPGP digital signature
