linux-kernel - Re: [PATCH V9 1/4] fuse: Definitions and ioctl() for passthrough

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20201022161254.GA36774@google.com>
Date:   Thu, 22 Oct 2020 17:12:54 +0100
From:   Alessio Balsini <balsini@...roid.com>
To:     Miklos Szeredi <miklos@...redi.hu>
Cc:     Alessio Balsini <balsini@...roid.com>,
        Akilesh Kailash <akailash@...gle.com>,
        Amir Goldstein <amir73il@...il.com>,
        Antonio SJ Musumeci <trapexit@...wn.link>,
        David Anderson <dvander@...gle.com>,
        Giuseppe Scrivano <gscrivan@...hat.com>,
        Jann Horn <jannh@...gle.com>, Jens Axboe <axboe@...nel.dk>,
        Martijn Coenen <maco@...roid.com>,
        Palmer Dabbelt <palmer@...belt.com>,
        Paul Lawrence <paullawrence@...gle.com>,
        Stefano Duo <stefanoduo@...gle.com>,
        Zimuzo Ezeozue <zezeozue@...gle.com>,
        fuse-devel <fuse-devel@...ts.sourceforge.net>,
        kernel-team <kernel-team@...roid.com>,
        linux-fsdevel@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH V9 1/4] fuse: Definitions and ioctl() for passthrough

On Wed, Sep 30, 2020 at 05:44:54PM +0200, Miklos Szeredi wrote:
> On Thu, Sep 24, 2020 at 3:13 PM Alessio Balsini <balsini@...roid.com> wrote:
> >
> > Introduce the new FUSE passthrough ioctl(), which allows userspace to
> > specify a direct connection between a FUSE file and a lower file system
> > file.
> > Such ioctl() requires userspace to specify:
> > - the file descriptor of one of its opened files,
> > - the unique identifier of the FUSE request associated with a pending
> >   open/create operation,
> > both encapsulated into a fuse_passthrough_out data structure.
> > The ioctl() will search for the pending FUSE request matching the unique
> > identifier, and update the passthrough file pointer of the request with the
> > file pointer referenced by the passed file descriptor.
> > When that pending FUSE request is handled, the passthrough file pointer
> > is copied to the fuse_file data structure, so that the link between FUSE
> > and lower file system is consolidated.
> 
> How about returning an ID from the ioctl (like the fuse2 porototype)
> and returning that in fuse_open_out.passthrough_fh?
> 
> Seems a more straightforward interface to me.
> 
> Thanks,
> Miklos

With this patch I tried to avoid any API modifications, for example,
changing fuse_open_out, doing everything at ioctl() time, and limiting the
allocation of dynamic memory.

In my next patch set (that I'll share as soon as I have enough hours of
testing with syzkaller) I implemented something similar to fuse2 in terms
of communication between kernel and userspace, with an id passing as you
recommended. So, userspace gets an id from the ioctl() and sends it back to
the kernel through the open/create reply, setting the passthrough_fh field
in fuse_open_out, that originally was the uint32_t padding. This wouldn't
change the fuse_open_out struct size, but is kind of an API breakage.

As in fuse2 I'm using IDR to generate the id and track the passthrough
entry information. On the other hand, compared to fuse2, I have one dynamic
IDR for each fuse_conn to prevent the owner of a connection from messing
with the ids of others.
In the upcoming patch set, the elements of each IDR serve the only purpose
of keeping track of the id in the timespan between the ioctl() and the
open/create reply. That IDR entry is removed right after the open/create
request is completed.
If in fuse2 the global IDR is queried for every read/write operation, my
new patch set would still create a "passthrough entry" for each fuse_file
to simplify the access to the lower file system at every read/write,
getting rid of IDR searches for each read/write operation.

Does this solution make sense?

I'm not sure that the upcoming solution is simpler than this one, but for
sure it keeps the interface more flexible and I like that it is moving in
the direction of fuse2.

Thanks,
Alessio