search

tytso / e2fsprogs

Ext2/3/4 file system utilities
http://ext4.wiki.kernel.org
381 stars 223 forks source link

Support fs-verity for `mkfs.ext4 -d` #201

Open allisonkarlitskaya opened 3 weeks ago

allisonkarlitskaya commented 3 weeks ago

When creating a new ext4 filesystem with -O verity enabled, -d ought to check if the files in the given directory are verity-enabled and — if they are — flag them for verity also in the new filesystem. This would require computing the merkle tree in userspace (which is definitely annoying, but wouldn't be so difficult).

This feature would be extremely helpful for creating OS images with fs-verity-enabled files inside of them, as we want to do in the composefs project.

allisonkarlitskaya commented 3 weeks ago

Actually, reading https://docs.kernel.org/filesystems/fsverity.html it looks like we could use FS_IOC_READ_VERITY_METADATA to get the existing fs-verity data out of the running host filesystem. That would substantially reduce the required effort here.

allisonkarlitskaya commented 3 weeks ago

I think I could write a patch for this, given confirmation that the idea is welcome and some guidance on the implementation approach. I'd probably add some code near the bottom of copy_file() in create_inode.c to call a function to read the fsverity data and write it in the manner described in https://docs.kernel.org/filesystems/ext4/overview.html#verity-files but maybe there is a better way?

tytso commented 1 week ago

I'm certainly willing to look at patches, so long as they are maintainable. Do you know how you plan to calculate the merkle tree in userspace? I suspect this may add some external dependencies in terms shared libraries? I always worry about bloating mke2fs or adding mandatory package depenndencies which tend to make distributions' release engineers cranky.

Solution to this might include having some separate binary to calculate the Merkle tree, since it might be something which is useful beyond just mke2fs -d (or maybe there is some external package which already has the Merkle tree calculation as a separate program) or using dlopen to dynamically load any shared libraries if they might happen to be necessary. We've done this before in e2fsprogs, but I suspect the first (having an external binary which mke2fs can run if mke2fs -d is requested to create a fsverity file system is the better one.

The other thing to consider is you want to control which files need to be have a Merkle tree attached, and whether you need to digitally sign the Merkle tree --- and if so, using which private / public key pair, and where to get access to the private key pair.

allisonkarlitskaya commented 1 week ago

I'm certainly willing to look at patches, so long as they are maintainable. Do you know how you plan to calculate the merkle tree in userspace? I suspect this may add some external dependencies in terms shared libraries? I always worry about bloating mke2fs or adding mandatory package depenndencies which tend to make distributions' release engineers cranky.

My reading of https://docs.kernel.org/filesystems/fsverity.html#fs-ioc-read-verity-metadata says that we can use the FS_IOC_READ_VERITY_METADATA to get the data directly from the running system. We would include exactly the data that we query from the host — no more, no less. I'm reasonably certain that this would be sufficient, and it would avoid us from having to encode any specific knowledge about fs-verity or merkle trees.

As for signing — I have no interest in this feature. I feel like it's probably not commonly used? Even the docs warn against it:

Please take great care before using this feature. It is not the only way to do signatures with fs-verity, and the alternatives (such as userspace signature verification, and IMA appraisal) can be much better. It’s also easy to fall into a trap of thinking this feature solves more problems than it actually does.

It's certainly not used for our usecase.