On 2024-06-12 12:06:44, Darrick J. Wong wrote: > 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 > Thanks, I will look into fscrypt and if it's feasible to make it work with xattrs in XFS or not. -- - Andrey
