On 2019/7/1 23:32, Eric Biggers wrote: > From: Eric Biggers <ebiggers@xxxxxxxxxx> > > Add fs-verity support to f2fs. fs-verity is a filesystem feature that > enables transparent integrity protection and authentication of read-only > files. It uses a dm-verity like mechanism at the file level: a Merkle > tree is used to verify any block in the file in log(filesize) time. It > is implemented mainly by helper functions in fs/verity/. See > Documentation/filesystems/fsverity.rst for the full documentation. > > The f2fs support for fs-verity consists of: > > - Adding a filesystem feature flag and an inode flag for fs-verity. > > - Implementing the fsverity_operations to support enabling verity on an > inode and reading/writing the verity metadata. > > - Updating ->readpages() to verify data as it's read from verity files > and to support reading verity metadata pages. > > - Updating ->write_begin(), ->write_end(), and ->writepages() to support > writing verity metadata pages. > > - Calling the fs-verity hooks for ->open(), ->setattr(), and ->ioctl(). > > Like ext4, f2fs stores the verity metadata (Merkle tree and > fsverity_descriptor) past the end of the file, starting at the first 64K > boundary beyond i_size. This approach works because (a) verity files > are readonly, and (b) pages fully beyond i_size aren't visible to > userspace but can be read/written internally by f2fs with only some > relatively small changes to f2fs. Extended attributes cannot be used > because (a) f2fs limits the total size of an inode's xattr entries to > 4096 bytes, which wouldn't be enough for even a single Merkle tree > block, and (b) f2fs encryption doesn't encrypt xattrs, yet the verity > metadata *must* be encrypted when the file is because it contains hashes > of the plaintext data. > > Acked-by: Jaegeuk Kim <jaegeuk@xxxxxxxxxx> > Signed-off-by: Eric Biggers <ebiggers@xxxxxxxxxx> Acked-by: Chao Yu <yuchao0@xxxxxxxxxx> Thanks,
