On Wed, 10 Apr 2024 at 01:50, Eric Biggers <ebiggers@xxxxxxxxxx> 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
