On Thu, Nov 17, 2022 at 9:19 PM Gmail <liuj97@xxxxxxxxx> wrote: > > Hello fuse-devel, > > The fs-verity framework provides file content integrity verification services for filesystems. Currently ext4/btrfs/f2fs has enabled support for fs-verity. Here I would like to propose implementing FUSE file content integrity verification based on fs-verity. > > Our current main use case is to support integrity verification for confidential containers using virtio-fs. With the new integrity verification feature, we can ensure that files from virtio-fs are trusted and fs-verity root digests are available for remote attestation. The integrity verification feature can also be used to support other FUSE based solutions. I'd argue FUSE isn't the right layer for supporting fs-verity verification. The verification can happen in the read path of virtio-fs (or any FUSE-based filesystem). In fact, Android is already doing this in "authfs" fully in userspace. Although FUSE lacks the support of "unrestricted" ioctl, which makes it impossible for the filesystem to receive the fs-verity ioctls. Same to statx. I think that's where we'd need a change in FUSE protocol. > > Fs-verity supports generating and verifying file content hash values. For the sake of simplicity, we may only support hash value verification of file content in the first stage, and enable support for hash value generation in the later stage. > > The following FUSE protocol changes are therefore proposed to support fs-verity: > 1) add flag “FUSE_FS_VERITY” to negotiate fs-verity support > 2) add flag “FUSE_ATTR_FSVERITY” for fuse servers to mark that inodes have associated fs-verity meta data. > 3) add op “FUSE_FSVERITY” to get/set fs-verity descriptor and hash values. > > The FUSE protocol does not specify how fuse servers store fs-verity metadata. The fuse server can store fs-verity metadata in its own ways. > > I did a quick prototype and the changes seems moderate, about 250 lines of code changes. > > Would love to hear about your feedback:) > > Thanks, > Gerry >
