On Thu, May 02, 2024 at 12:01:32AM +0000, Eric Biggers wrote: > On Wed, May 01, 2024 at 03:47:36PM -0700, Darrick J. Wong wrote: > > On Tue, Apr 30, 2024 at 11:47:23PM -0700, Christoph Hellwig wrote: > > > On Mon, Apr 29, 2024 at 08:29:03PM -0700, Darrick J. Wong wrote: > > > > From: Darrick J. Wong <djwong@xxxxxxxxxx> > > > > > > > > Now that fsverity tells our merkle tree io functions about what a hash > > > > of a data block full of zeroes looks like, we can use this information > > > > to avoid writing out merkle tree blocks for sparse regions of the file. > > > > For verified gold master images this can save quite a bit of overhead. > > > > > > Is this something that fsverity should be doing in a generic way? > > > > I don't think it's all that useful for ext4/f2fs because they always > > write out full merkle tree blocks even if it's the zerohash over and > > over again. Old kernels aren't going to know how to deal with that. > > > > > It feels odd to have XFS behave different from everyone else here, > > > even if this does feel useful. Do we also need any hash validation > > > that no one tampered with the metadata and added a new extent, or > > > is this out of scope for fsverity? > > > > If they wrote a new extent with nonzero contents, then the validation > > will fail, right? > > > > If they added a new unwritten extent (or a written one full of zeroes), > > then the file data hasn't changed and validation would still pass, > > correct? > > The point of fsverity is to verify that file data is consistent with the > top-level file digest. It doesn't really matter which type of extent the data > came from, or if the data got synthesized somehow (e.g. zeroes synthesized from > a hole), as long as fsverity still gets invoked to verify the data. If the data > itself passes verification, then it's good. The same applies to Merkle tree > blocks which are an intermediate step in the verification. <nod> > In the Merkle tree, ext4 and f2fs currently just use the same concept of > sparsity as the file data, i.e. when a block is unmapped, it is filled in with > all zeroes. As Darrick noticed, this isn't really the right concept of sparsity > for the Merkle tree, as a block full of hashes of zeroed blocks should be used, > not literally a zeroed block. I think it makes sense to fix this in XFS, as > it's newly adding fsverity support, and this is a filesystem-level > implementation detail. It would be difficult to fix this in ext4 and f2fs since > it would be an on-disk format upgrade. (Existing files should not actually have > any sparse Merkle tree blocks, so we probably could redefine what they mean. > But even if so, old kernels would not be able to read the new files.) <nod> --D > - Eric >
