From: Victor Hsieh <victorhsieh@google.com>
To: Gerry Liu <liuj97@gmail.com>
Cc: Eric Biggers <ebiggers@google.com>,
Miklos Szeredi <miklos@szeredi.hu>,
"Theodore Y. Ts'o" <tytso@mit.edu>,
linux-fsdevel@vger.kernel.org, linux-fscrypt@vger.kernel.org,
fuse-devel@lists.sourceforge.net
Subject: Re: Feature proposal: support file content integrity verification based on fs-verity
Date: Thu, 1 Dec 2022 15:42:35 -0800 [thread overview]
Message-ID: <CAFCauYPGtUHyu+hjET97YnG+a3hraeGTaMeR=wUm8duKu=w7fw@mail.gmail.com> (raw)
In-Reply-To: <8242669C-B41F-4310-A244-973D9793E652@gmail.com>
On Thu, Dec 1, 2022 at 1:51 AM Gerry Liu <liuj97@gmail.com> wrote:
>
>
>
> > 2022年11月29日 08:44，Victor Hsieh <victorhsieh@google.com> 写道：
> >
> > On Thu, Nov 17, 2022 at 9:19 PM Gmail <liuj97@gmail.com> 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.
> Hi Victor,
> Thanks for your comments:)
>
> There’s a trust boundary problem here. There are two possible ways to verify data integrity:
> 1) verify data integrity in fuse kernel driver
> 2) verify data integrity in fuse server.
>
> For hardware TEE(Trusted Execution Environment) based confidential vm/container with virtio-fs, the fuse server running on the host side is outside of trust domain, and the fuse driver is inside of trust domain. It is therefore recommended to verify data integrity in the fuse driver. The same situation may exist for fuse device based fuse server. The application trusts kernel but doesn’t trust the fuse server.
It sounded like your case is similar to ours: the storage isn't
considered trusted (across the VM boundary). Note that fs-verity can
only give you the consistent (and efficient) file measurement over the
file content. If your storage is not trusted, you do have to ensure
the measurement of the *file paths* are the expected values, otherwise
the attacker can replace/rename one file with another. For example,
the trusted process would have to know a mapping from file name to the
measurement, and check the measurement of the fs-verity-enabled files
before every open. I can see how supporting fs-verity in virtio-fs
can be a stepping stone to solving your problem, but I'm not in a good
position to suggest whether it's a good idea or not. But we did solve
our problem purely in userspace also using FUSE.
>
> Thanks,
> Gerry
>
> >
> > 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
> >>
>
prev parent reply other threads:[~2022-12-01 23:42 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-11-18 5:19 Feature proposal: support file content integrity verification based on fs-verity Gmail
2022-11-29 0:44 ` Victor Hsieh
2022-12-01 9:51 ` Gerry Liu
2022-12-01 23:42 ` Victor Hsieh [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CAFCauYPGtUHyu+hjET97YnG+a3hraeGTaMeR=wUm8duKu=w7fw@mail.gmail.com' \
--to=victorhsieh@google.com \
--cc=ebiggers@google.com \
--cc=fuse-devel@lists.sourceforge.net \
--cc=linux-fscrypt@vger.kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=liuj97@gmail.com \
--cc=miklos@szeredi.hu \
--cc=tytso@mit.edu \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).