On Tue, Apr 11, 2023 at 07:33:19PM -0700, Eric Biggers wrote:
> 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.
Well, that and some of the XFS internal changes that seem a bit ugly.
But it's not only very much tied to the page cache, but also to
page aligned data, which is really part of the problem.
> 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.
That seems to be the worst of both worlds.
> 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.
xattrs contents better be encrypted as well, fsverity or not.
