On Jan 28, 2018, at 6:03 PM, Theodore Ts'o <tytso@xxxxxxx> wrote: > > So if there as a solution which enapculated the information needed to > create the fs-verity header and the PKCS7 signature in an xattr --- > which is how you carry it around in the tar image --- and when the > tarfile is unpacked, the software which does the unpacking calls a > library which checks for the xattr, removes it, writes out the > fsverity header and Merkle tree, and then calls the ioctl which sets > the "verity" bit, thus instantiating the data integrity protection, > would this meet your requirements? > > In other words, the xattr in the tar file is just the method for > carrying the information; and (a) it is not how the information would > be stored in the underlying file system when it is actually used, and > (b) it requires the userspace code to do this transformation, so we > don't have to build the Merkle tree in the kernel. Is this sufficient > for your container use case? Why would you throw away the xattr signature at that point? That would still be useful to store back into a new tarball or other backup of the file, and is also useful for external tools to verify (e.g. bittorrent, maybe rsync or others in the future), especially if it is a common format. That doesn't mean storing the whole fs-verity tree in an xattr (though that could also be done with the ext4 xattr inode feature), nor does it imply that this is a "magic" xattr that causes the fs-verity tree to be created when written. It would just be an xattr that stores the top-level hash of the Merkle tree to expose to userspace. Also, the Merkle tree should be computed with fixed-size leaf blocks like 1KB or 4KB, so that userspace doesn't need to know details like the underlying fs blocksize. The actual on-disk fs-verity tree can be stored in fs blocksize units, and if the blocksize is larger than the leaf blocks it would just store a higher-level node in the Merkle tree. We actually worked on a design for this years ago with Lustre+ZFS, with sending higher-level nodes in the Merkle tree over the network for the RPC checksum so that it is independent of the client/server PAGE_SIZE, the RPC size and the underlying fs blocksize, but this would also be useful for storage in tarballs or for read/write requests with fs-verity. For more details see: http://wiki.old.lustre.org/images/c/c1/End-to-End-Integrity-2009-06-15.pdf Cheers, Andreas
Attachment:
signature.asc
Description: Message signed with OpenPGP
