Re: [PATCH 1/1] fuse: Add initial support for fs-verity

From: Miklos Szeredi <miklos@szeredi.hu>
To: Eric Biggers <ebiggers@kernel.org>
Cc: Richard Fung <richardfung@google.com>,
	linux-fsdevel@vger.kernel.org,  fsverity@lists.linux.dev
Subject: Re: [PATCH 1/1] fuse: Add initial support for fs-verity
Date: Thu, 11 Apr 2024 08:06:37 +0200	[thread overview]
Message-ID: <CAJfpegt9hBADfGEAdsBjNShYHB68o7c=gHN29SZHqekdnYzkNA@mail.gmail.com> (raw)
In-Reply-To: <20240409235018.GC1609@quark.localdomain>

On Wed, 10 Apr 2024 at 01:50, Eric Biggers <ebiggers@kernel.org> wrote:

> I am fine with having FUSE support passing through FS_IOC_MEASURE_VERITY and
> FS_IOC_ENABLE_VERITY.
>
> As you may have noticed, these ioctls are a bit more complex than the simple
> ones that FUSE allows already.  The argument to FS_IOC_MEASURE_VERITY has a
> variable-length trailing array, and the argument to FS_IOC_ENABLE_VERITY has up
> to two pointers to other buffers.
>
> I am hoping the FUSE folks have thoughts on what is the best way to support
> ioctls like these.  I suspect that this patch (with the special handling in
> FUSE) may be the only feasible approach, but I haven't properly investigated it.

Ideally I'd imagine something something similar to how we handle
FS_IOC_GETFLAGS/SETFLAGS.

Exceptions for those were also added in commit 31070f6ccec0 ("fuse:
Fix parameter for FS_IOC_{GET,SET}FLAGS").  But then infrastructure
was added to the vfs (commit 4c5b47997521 ("vfs: add fileattr ops"))
so that filesystems can handle these as normal callbacks instead of
dealing with ioctls directly.

In the fsverity case this is not such a clear cut case, since only
fuse (and possible network fs?) would actually implement the vfs
callback, others would just set the default handler from fsverity.  So
I don't insist on doing this, just saying that it would be the
cleanest outcome.

If we do add exceptions, the requirement from me is that it's split
out into a separate function from fuse_do_ioctl().

Thanks,
Miklos