Re: [PATCH 18/26] xfs: use merkle tree offset as attr hash

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

 



On Mon, May 20, 2024 at 09:02:59AM -0700, Darrick J. Wong wrote:
> On Mon, May 20, 2024 at 05:39:59AM -0700, Christoph Hellwig wrote:
> > On Fri, May 17, 2024 at 10:17:20AM -0700, Darrick J. Wong wrote:
> > > >   Note that the verity metadata *must* be encrypted when the file is,
> > > >   since it contains hashes of the plaintext data.
> > > 
> > > Refresh my memory of fscrypt -- does it encrypt directory names, xattr
> > > names, and xattr values too?  Or does it only do that to file data?
> > 
> > It does encrypt the file names in the directories, but nothing in
> > xattrs as far as I can tell.
> 
> Do we want that for user.* attrs?  That seems like quite an omission.

I'll let Eric answer that.  Btw, is the threat model for fscrypt written
down somewhere?

> > > And if we copy the ext4 method of putting the merkle data after eof and
> > > loading it into the pagecache, how much of the generic fs/verity cleanup
> > > patches do we really need?
> > 
> > We shouldn't need anything.  A bunch of cleanup
> 
> Should we do the read/drop_merkle_tree_block cleanup anyway?

To me the block based interface seems a lot cleaner, but Eric has some
reservations due to the added indirect call on the drop side.

> One of the advantages of xfs caching merkle tree blocks ourselves
> is that we neither extend the usage of PageChecked when merkle blocksize
> == pagesize nor become subject to the 1-million merkle block limit when
> merkle blocksize < pagesize.  There's a tripping hazard if you mount a 4k
> merkle block filesystem on a computer with 64k pages -- now you can't
> open 6T verity files.
> 
> That said, it also sounds dumb to maintain a separate index for
> pagecache pages to track a single bit.

Yeah.  As I mentioned earlier I think fsverify really should enforce
a size limit.  Right now it will simply run out space eventually which
doesn't seem like a nice failure mode.

> Maybe we should port verity to
> use xbitmap64 from xfs instead of single static buffer?

The seems like a bit of overkill for the current use cases.





[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