On Thu, Mar 07, 2024 at 07:46:50PM -0800, Darrick J. Wong wrote: > On Thu, Mar 07, 2024 at 02:02:24PM -0800, Eric Biggers wrote: > > On Wed, Mar 06, 2024 at 08:30:00AM -0800, Darrick J. Wong wrote: > > > Or you could leave the unfinished tree as-is; that will waste space, but > > > if userspace tries again, the xattr code will replace the old merkle > > > tree block contents with the new ones. This assumes that we're not > > > using XATTR_CREATE during FS_IOC_ENABLE_VERITY. > > > > This should work, though if the file was shrunk between the FS_IOC_ENABLE_VERITY > > that was interrupted and the one that completed, there may be extra Merkle tree > > blocks left over. > > What if ->enable_begin walked the xattrs and trimmed out any verity > xattrs that were already there? Though I think ->enable_end actually > could do this since one of the args is the tree size, right? If we are overwriting xattrs, it's effectively a remove then a new create operation, so we may as well just add a XFS_ATTR_VERITY namespace invalidation filter that removes any xattr in that namespace in ->enable_begin... > > BTW, is xfs_repair planned to do anything about any such extra blocks? > > Sorry to answer your question with a question, but how much checking is > $filesystem expected to do for merkle trees? > > In theory xfs_repair could learn how to interpret the verity descriptor, > walk the merkle tree blocks, and even read the file data to confirm > intactness. If the descriptor specifies the highest block address then > we could certainly trim off excess blocks. But I don't know how much of > libfsverity actually lets you do that; I haven't looked into that > deeply. :/ Perhaps a generic fsverity userspace checking library we can link in to fs utilities like e2fsck and xfs_repair is the way to go here. That way any filesystem that supports fsverity can do offline validation of the merkle tree after checking the metadata is OK if desired. > For xfs_scrub I guess the job is theoretically simpler, since we only > need to stream reads of the verity files through the page cache and let > verity tell us if the file data are consistent. *nod* > For both tools, if something finds errors in the merkle tree structure > itself, do we turn off verity? Or do we do something nasty like > truncate the file? Mark it as "data corrupt" in terms of generic XFS health status, and leave it up to the user to repair the data and/or recalc the merkle tree, depending on what they find when they look at the corrupt file status. > Is there an ioctl or something that allows userspace to validate an > entire file's contents? Sort of like what BLKVERIFY would have done for > block devices, except that we might believe its answers? > > Also -- inconsistencies between the file data and the merkle tree aren't > something that xfs can self-heal, right? Not that I know of - the file data has to be validated before we can tell if the error is in the data or the merkle tree, and only the user can validate the data is correct. -Dave. -- Dave Chinner david@xxxxxxxxxxxxx
