From mboxrd@z Thu Jan 1 00:00:00 1970 From: Christoph Hellwig Date: Wed, 12 Apr 2023 05:40:24 -0700 Subject: [Cluster-devel] [PATCH v2 00/23] fs-verity support for XFS In-Reply-To: <20230412023319.GA5105@sol.localdomain> References: <20230404145319.2057051-1-aalbersh@redhat.com> <20230412023319.GA5105@sol.localdomain> Message-ID: List-Id: To: cluster-devel.redhat.com MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit 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.