Message-ID: <CA+PiJmQR17nwkHaZXUhw=YRM06TfF14bhozc=nM9cw51aiiB6g@mail.gmail.com>
Date: Fri, 29 Mar 2024 17:59:30 -0700
From: Daniel Rosenberg <drosen@...gle.com>
To: Amir Goldstein <amir73il@...il.com>
Cc: Miklos Szeredi <miklos@...redi.hu>, bpf@...r.kernel.org, 
	Alexei Starovoitov <ast@...nel.org>, linux-kernel@...r.kernel.org, 
	linux-fsdevel@...r.kernel.org, linux-unionfs@...r.kernel.org, 
	Daniel Borkmann <daniel@...earbox.net>, John Fastabend <john.fastabend@...il.com>, 
	Andrii Nakryiko <andrii@...nel.org>, Martin KaFai Lau <martin.lau@...ux.dev>, Song Liu <song@...nel.org>, 
	Eduard Zingerman <eddyz87@...il.com>, Yonghong Song <yonghong.song@...ux.dev>, 
	KP Singh <kpsingh@...nel.org>, Stanislav Fomichev <sdf@...gle.com>, Hao Luo <haoluo@...gle.com>, 
	Jiri Olsa <jolsa@...nel.org>, Shuah Khan <shuah@...nel.org>, Jonathan Corbet <corbet@....net>, 
	Joanne Koong <joannelkoong@...il.com>, Mykola Lysenko <mykolal@...com>, 
	Christian Brauner <brauner@...nel.org>, kernel-team@...roid.com, 
	Bernd Schubert <bschubert@....com>
Subject: Re: [RFC PATCH v4 00/36] Fuse-BPF and plans on merging with Fuse Passthrough

On Thu, Mar 28, 2024 at 11:45 PM Amir Goldstein <amir73il@...il.com> wrote:
>
> My plan was to start from passthrough ioctl with O_PATH fd on lookup
> and deal with performance improvements later when there are actual
> workloads that report a problem and that depends where the overhead is.
>
> Is it with the opening of O_PATH fds?
> Is it with the passthtough ioctls?
> If latter, then when fuse uring is merged, I think we could get loose
> the ioctls anyway.
>

I'm not terribly sure. Ideally I would have cc'ed them on this email,
but I didn't take down contact info with my notes. I was under the
impression that it was triggering all of the opens before an actual
open was needed, for example, during ls -l, but I don't know if that
was with O_PATH fds. I was a bit concerned that a performance fix
there might end up needing a different interface, and managing
multiple of those could get pretty cluttered. But I agree that it
doesn't make sense to do anything there without a concrete use-case
and issue.

>
> The original reason was to mitigate an attack vector of fooling a
> privileged process into writing the fd (number) to /dev/fuse to
> gain access to a backing file this way.
>
> The fuse-bpf way of doing all responds with ioctls seems fine for
> this purpose, but note that the explicit setup also provides feedback
> to the server in case the passthrough cannot be accomplished
> for a specific inode (e.g. because of stacking depths overflow)
> and that is a big benefit IMO.
>

That certainly informs the daemon of the error earlier. So long as we
can still run the complete passthrough mode serverless that's fine by
me. I've found that mode helpful for running filesystem tests on pure
backing mode, plus I imagine some simple Fuse filesystems could get
away with only the bpf programs.

>
> Using a global cred should be fine, just as overlayfs does.
> The specific inode passthrough setup could mention if the global
> cred should be used.
>
> However, note that overlayfs needs to handle some special cases
> when using mounter creds (e.g.: ovl_create_or_link() and dropping
> of CAP_SYS_RESOURCE).
>
> If you are going to mimic all this, better have that in the stacking fs
> common code.
>

Sure. The less duplicate code the better :)

>
> That sounds like a good plan, but also, please remember Miklos' request -
> please split the patch sets for review to:
> 1. FUSE-passthrough-all-mode
> 2. Attach BPF program
>
> We FUSE developers must be able to review the FUSE/passthough changes
> without any BPF code at all (which we have little understanding thereof)
>
> As a merge strategy, I think we need to aim for merging all the FUSE
> passthrough infrastructure needed for passthrough of inode operations
> strictly before merging any FUSE-BPF specific code.
>
> In parallel you may get BPF infrastructure merged, but integrating FUSE+BPF,
> should be done only after all infrastructure is already merged IMO.
>

Ok. I'll probably mess around with the module stuff at least, in order
to work out if everything I need is present on the bpf side. Do you
know if anyone is actively working on extending the file-backing work
to something like inode-backing? I don't want to duplicate work there,
but I'd be happy to start looking at it. Otherwise I'd focus on the
bpf end for now. I expect we'll want to be able to optionally set the
bpf program at the same place where we set the backing file/inode.
Hence the spit into a file and inode program set. I'm still thinking
over what the best way to address the programs is...

>
> So I don't think there is any point in anyone actually reviewing the
> v4 patch set that you just posted?
>

Correct. The only reason I included it was as a reference for the sort
of stuff fuse-bpf is currently doing.

>
> Please explain what you mean by that.
> How are fuse-bpf file operations expected to be used and specifically,
> How are they expected to extend the current FUSE passthrough functionality?
>
> Do you mean that an passthrough setup will include a reference to a bpf
> program that will be used to decide per read/write/splice operation
> whether it should be passed through to backing file or sent to server
> direct_io style?
>

So in the current fuse-bpf setup, the bpf program does two things. It
can edit certain parameters, and it can indicate what the next action
should be. That action could be queuing up the post filter after the
backing operation, deferring to a userspace pre/post filter, or going
back to normal fuse operations.
The latter one isn't currently very well fleshed out. Unless you do
some specific tracking, under existing fuse-bpf you'd have a node id
of 0, and userspace can't make much out of that. With that aside,
there's all sorts of caching nightmares to deal with there.

We're only using the parameter changing currently in our use cases. I
wouldn't be opposed to leaving the falling back to fuse for specific
operations out of v1 of the bpf enhancements, especially if we have
the userspace pre/post filters available.
So you'd optionally specify a bpf program to use with the backing
file. That would allow you to manipulate some data in the files like
you might in Fuse itself. For instance, data redaction. You could null
out location metadata in images, provided a map or something with the
offsets that should be nulled. You could also prepend some data at the
beginning of a file by adjusting offsets and attrs and whatnot. I
could imagine having multiple backing files, and the bpf program
splitting a read into multiple parts to handle parts of it using
different backing files, although that's not in the current design.

>
> I just wanted to make sure that you are aware of the fact that direct io
> to server is the only mode of io that is allowed on an inode with an attached
> backing file.
>
> Thanks,
> Amir.
>

Can you not read/write without interacting with the server? Or do you
mean FOPEN_DIRECT_IO sends some file ops to the server even in
passthrough mode? At the moment I'm tempted to follow the same
mechanics passthrough is using. The only exception would be possibly
tossing back to the server, which I mentioned above. That'd only
happen for, say, read, if we're not under FOPEN_DIRECT_IO. I've not
looked too closely at FOPEN_DIRECT_IO. In Fuse bpf we currently have
bpf mode taking priority. Are there any email threads I should look at
for more background there?

-Daniel

Powered by blists - more mailing lists