Re: [PATCH v5 06/24] fsverity: pass tree_blocksize to end_enable_verity()

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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?

(Hmm that still wouldn't be any guarantee of success since those xattr
remove calls are each separate transactions...)

> 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. :/

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.

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?

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?

--D

> - Eric
> 




[Index of Archives]     [XFS Filesystem Development (older mail)]     [Linux Filesystem Development]     [Linux Audio Users]     [Yosemite Trails]     [Linux Kernel]     [Linux RAID]     [Linux SCSI]


  Powered by Linux