On Tue, May 05, 2020 at 08:39:21PM +0800, Qu Wenruo wrote: > > 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. Technical note: no unnecessary mount options, reuse the auth_key with some special value.
