On Fri, Aug 24, 2018, at 12:16 PM, Eric Biggers wrote: > From: Eric Biggers <ebiggers@xxxxxxxxxx> > > fs-verity is a filesystem feature that provides efficient, transparent > integrity verification and authentication of read-only files. It uses a > dm-verity like mechanism at the file level: a Merkle tree hidden past > the end of the file is used to verify any block in the file in > log(filesize) time. It is implemented mainly by helper functions in > fs/verity/ that will be shared by multiple filesystems. > > Essentially, fs-verity reports a file's hash in constant time, but reads > that would violate that hash fail at runtime. This is useful when only > a portion of the file is actually accessed, as only the accessed portion > has to be hashed, and the latency to the first read is much reduced over > a full file hash. On top of this hashing mechanism, auditing or > authentication policies can be implemented to log or verify file hashes. > > Note that in general, fs-verity is *not* a replacement for IMA. > fs-verity is a lower-level feature, primarily a way to hash a file; > whereas IMA deals more with higher-level policy logic, like defining > which files are "measured" and what to do with those measurements. We > plan for IMA to support fs-verity measurements as an alternative to the > traditional full file hash. Still, some users find fs-verity useful by > itself, so it's also usable without IMA in simple cases, e.g. in cases > where just retrieving the file measurement via an ioctl is enough. > > A structure containing the properties of the Merkle tree -- such as the > hash algorithm used, the block size, and the root hash -- is also stored > on-disk, following the Merkle tree. The actual file measurement hash > that fs-verity reports is the hash of this structure. > > All fs-verity metadata is written by userspace; the kernel only reads > it. Extended attributes aren't used because the Merkle tree may be much > larger than XATTR_SIZE_MAX, we want the hash pages to be cached in the > page cache as usual, and in the case of fs-verity combined with fscrypt > we want the metadata to be encrypted to avoid leaking plaintext hashes. > The fs-verity metadata is hidden from userspace by overriding the i_size > of the in-memory VFS inode; ext4 additionally will override the on-disk > i_size in order to make verity a RO_COMPAT filesystem feature. > > This initial patch only adds the fs-verity Kconfig option, UAPI, and > setup code, e.g. the ->open() hook that parses the fs-verity descriptor. This first patch also adds a bit of core logic in the simple fsverity_prepare_setattr() which ends up being called by ext4 later. While I'm not too familiar with the vfs, as far as I can tell from inspection of Linus' git master is that pretty much any change (timestamp, hardlinks) ends up calling notify_change() which calls the fs-specific one, and in the verity case basically denies everything, right? Previously I brought up many uses for "content immutable" files: https://marc.info/?l=linux-fsdevel&m=151698481512084&w=2 The discussion sort of died out but...did you have any opinion on e.g. my proposal to use the Unix mode bits as a way to describe levels of mutablility? Let's say that your new _VERITY inode flag becomes "_WRITEPROT" or something a bit more generic. Do you have any thoughts on my proposal to reuse the Unix mode bits to control levels of inode mutability? For example, it seems to me we could define u+w as "hardlinks are OK". There shouldn't be any reason ext4/f2fs couldn't hardlink a verity-protected inode right? Or if for some reason that is hard, we could disallow that to start, but at least have the core VFS support _WRITEPROT inodes?
