Hi Andrey, Yesterday during office hours I mentioned that I was going to hand the xfs fsverity patchset back to you once I managed to get a clean fstests run on my 6.10 tree. I've finally gotten there, so I'm ready to transfer control of this series back to you: https://git.kernel.org/pub/scm/linux/kernel/git/djwong/xfs-linux.git/log/?h=fsverity_2024-06-12 https://git.kernel.org/pub/scm/linux/kernel/git/djwong/xfsprogs-dev.git/log/?h=fsverity_2024-06-12 https://git.kernel.org/pub/scm/linux/kernel/git/djwong/xfstests-dev.git/log/?h=fsverity_2024-06-12 At this point, we have a mostly working implementation of fsverity that's still based on your original design of stuffing merkle data into special ATTR_VERITY extended attributes, and a lightweight buffer cache for merkle data that can track verified status. No contiguously allocated bitmap required, etc. At this point I've done all the design and coding work that I care to do, EXCEPT: Unfortunately, the v5.6 review produced a major design question that has not been resolved, and that is the question of where to store the ondisk merkle data. Someone (was it hch?) pointed out that if xfs were to store that fsverity data in some post-eof range of the file (ala ext4/f2fs) then the xfs fsverity port wouldn't need the large number of updates to fs/verity; and that a future xfs port to fscrypt could take advantage of the encryption without needing to figure out how to encrypt the verity xattrs. On the other side of the fence, I'm guessing you and Dave are much more in favor of the xattr method since that was (and still is) the original design of the ondisk metadata. I could be misremembering this, but I think willy isn't a fan of the post-eof pagecache use either. I don't have the expertise to make this decision because I don't know enough (or anything) about cryptography to know just how difficult it actually would be to get fscrypt to encrypt merkle tree data that's not simply located in the posteof range of a file. I'm aware that btrfs uses the pagecache for caching merkle data but stores that data elsewhere, and that they are contemplating an fscrypt implementation, which is why Sweet Tea is on the cc list. Any thoughts? (This is totally separate from fscrypt'ing regular xattrs.) If it's easy to adapt fscrypt to encrypt fsverity data stored in xattrs then I think we can keep the current design of the patchset and try to merge it for 6.11. If not, then I think the rest of you need to think hard about the tradeoffs and make a decision. Either way, the depth of my knowledge about this decision is limited to thinking that I have a good enough idea about whom to cc. Other notes about the branches I linked to: I think it's safe to skip all the patches that mention disabling fsverity because that's likely DOA anyway. Christoph also has a patch to convert the other fsverity implementations (btrfs/ext4/f2fs) to use the read/drop_merkle_tree_block interfaces: https://lore.kernel.org/linux-xfs/ZjMZnxgFZ_X6c9aB@xxxxxxxxxxxxx/ I'm not sure if it actually handles PageChecked for the case that the merkle tree block size != base page size. If you prefer I can patchbomb the list with this v5.7 series. --Darrick
