Yet another try for fs-verity

Posted Jun 3, 2019 23:53 UTC (Mon) by jhoblitt (subscriber, #77733)
Parent article: Yet another try for fs-verity

Why not use an xattr so user space had some way of detecting these magic files without having to try an unusual ioctl on every file. It would also be nice, regardless of the config interface, if a protected file always showed the immutable bit as true.

Yet another try for fs-verity

Posted Jun 4, 2019 0:34 UTC (Tue) by skissane (subscriber, #38675) [Link] (2 responses)

> Why not use an xattr so user space had some way of detecting these magic files without having to try an unusual ioctl on every file

The documentation https://lwn.net/ml/linux-fsdevel/20190523161811.6259-2-eb... explains why this wasn't done:
1) many file systems impose a small limit on the extended attribute value size (e.g. 4096 bytes on F2FS), while these Merkle trees can be very big
2) other file systems support very big extended attribute values in theory, but perform very poorly with them (e.g. ext4)
3) some filesystems (e.g. ext4) support file encryption. Since the Merkle tree is based on the plaintext not the ciphertext, in that case the Merkle tree needs to be encrypted as well. However, while ext4 supports file encryption, it doesn't support the encryption of the extended attributes

All the above flaws in extended attribute support probably can and should be fixed. But it is a lot of work, especially since it is a problem across multiple filesystems. Not using extended attributes for this feature is a way to deliver this feature without being blocked by the need to fix those above flaws.

I guess another option would be to have an extended attribute which indicates the presence of a Merkle tree, but doesn't actually store the Merkle tree data. That would meet your requirement (for an easy way for user space to detect the feature is enabled on any given file) without running up against the above extended attribute limitations.

> It would also be nice, regardless of the config interface, if a protected file always showed the immutable bit as true

I agree with that.

Yet another try for fs-verity

Posted Jun 4, 2019 2:23 UTC (Tue) by jhoblitt (subscriber, #77733) [Link] (1 responses)

What I was suggesting is that the same configuration as is proposed to be passed via ioctl is set as xattrs, while the checksum metadata tree still remains "hidden".

Yet another try for fs-verity

Posted Jun 4, 2019 2:43 UTC (Tue) by ebiggers (subscriber, #130760) [Link]

The documentation covers why the Merkle tree isn't stored in xattrs on ext4 and f2fs. Independently of that, in theory the API *could* use xattrs instead of ioctls, e.g. FS_IOC_ENABLE_VERITY could be replaced with setxattr("system.fsverity", &fsverity_enable_arg), and FS_IOC_MEASURE_VERITY replaced with getxattr("system.fsverity"). However, abusing the xattr interface for basically arbitrary syscalls is heavily frowned upon by most of the Linux filesystem developers. An xattr should really just be an xattr on-disk, not an API to e.g. magically trigger construction of a Merkle tree.

We're still planning to expose the verity bit through FS_IOC_GETFLAGS and possibly statx() too, just like the encrypt bit. So detecting verity files will still be straightforward; you don't need xattrs for this.

We aren't using the existing "immutable" bit because it already has specific semantics that include much more than just file contents immutability, e.g. it also prevents the file from being deleted, renamed, linked to, or have its owner or mode changed. So reusing the immutable bit to mean "fs-verity enabled" would not be appropriate.