On Nov 1, 2018, at 4:52 PM, Eric Biggers <ebiggers@xxxxxxxxxx> wrote: > > From: Eric Biggers <ebiggers@xxxxxxxxxx> > > Add basic fs-verity support to ext4. 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 details. > > This patch adds everything except the data verification hooks that will > needed in ->readpages(). > > On ext4, enabling fs-verity on a file requires that the filesystem has > the 'verity' feature, e.g. that it was formatted with > 'mkfs.ext4 -O verity' or had 'tune2fs -O verity' run on it. > This requires e2fsprogs 1.44.4-2 or later. > > In ext4, we choose to retain the fs-verity metadata past the end of the > file rather than trying to move it into an external inode xattr, since > in practice keeping the metadata in-line actually results in the > simplest and most efficient implementation. One non-obvious advantage > of keeping the verity metadata in-line is that when fs-verity is > combined with fscrypt, the verity metadata naturally gets encrypted too; > this is actually necessary because it contains hashes of the plaintext. On the plus side, this means that the verity data will automatically be invalidated if the file is truncated or extended, but on the negative side it means that the verity Merkle tree needs to be recalculated for the entire file if e.g. the file is appended to. I guess the current implementation will generate the Merkle tree in userspace, but at some point it might be useful to generate it on-the-fly to have proper data integrity from the time of write (e.g. like ZFS) rather than only allowing it to be stored after the entire file is written? Storing the Merkle tree in a large xattr inode would allow this to change in the future rather than being stuck with the current implementation. We could encrypt the xattr data just as easily as the file data (which should be done anyway even for non-verity files to avoid leaking data), and having the verity attr keyed to the inode version/size/mime(?) would ensure the kernel knows it is stale if the inode is modified. I'm not going to stand on my head and block this implementation, I just thought it is worthwhile to raise these issues now rather than after it is a fait accompli. > We also choose to keep the on-disk i_size equal to the original file > size, in order to make the 'verity' feature a RO_COMPAT feature. Thus, > ext4 has to find the fsverity_footer by looking in the last extent. Cheers, Andreas
Attachment:
signature.asc
Description: Message signed with OpenPGP
