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

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

 



FYI, I spent some time looking over the core verity and ext4 code,
and I can't find anything enforcing any kind of size limit.  Of course
testing that is kinda hard without taking sparseness into account.

Eric, should fsverity or the fs backend check for a max size instead
od trying to build the merkle tree and evnetually failing to write it
out?

An interesting note I found in the ext4 code is:

  Note that the verity metadata *must* be encrypted when the file is,
  since it contains hashes of the plaintext data.

While xfs doesn't currently support fscrypyt it would actually be very
useful feature, so we're locking us into encrypting attrs or at least
magic attr fork data if we do our own non-standard fsverity storage.
I'm getting less and less happy with not just doing the normal post
i_size storage.  Yes, it's not pretty (so isn't the whole fsverity idea
of shoehorning the hashes into file systems not built for it), but it
avoid adding tons of code and beeing very different.




[Index of Archives]     [Linux Ext4 Filesystem]     [Union Filesystem]     [Filesystem Testing]     [Ceph Users]     [Ecryptfs]     [NTFS 3]     [AutoFS]     [Kernel Newbies]     [Share Photos]     [Security]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux Cachefs]     [Reiser Filesystem]     [Linux RAID]     [NTFS 3]     [Samba]     [Device Mapper]     [CEPH Development]

  Powered by Linux