On Mon, Apr 10, 2023 at 10:19:46PM -0700, Christoph Hellwig wrote: > Dave is going to hate me for this, but.. > > I've been looking over some of the interfaces here, and I'm starting > to very seriously questioning the design decisions of storing the > fsverity hashes in xattrs. > > Yes, storing them beyond i_size in the file is a bit of a hack, but > it allows to reuse a lot of the existing infrastructure, and much > of fsverity is based around it. So storing them in an xattrs causes > a lot of churn in the interface. And the XFS side with special > casing xattr indices also seems not exactly nice. It seems it's really just the Merkle tree caching interface that is causing problems, as it's currently too closely tied to the page cache? That is just an implementation detail that could be reworked along the lines of what is being discussed. But anyway, it is up to the XFS folks. Keep in mind there is also the option of doing what btrfs is doing, where it stores the Merkle tree separately from the file data stream, but caches it past i_size in the page cache at runtime. I guess there is also the issue of encryption, which hasn't come up yet since we're talking about fsverity support only. The Merkle tree (including the fsverity_descriptor) is supposed to be encrypted, just like the file contents are. Having it be stored after the file contents accomplishes that easily... Of course, it doesn't have to be that way; a separate key could be derived, or the Merkle tree blocks could be encrypted with the file contents key using indices past i_size, without them physically being stored in the data stream. - Eric
