Re: [MAINTAINERS/KERNEL SUMMIT] Trust and maintenance of file systems

[Dave Chinner <david@fromorbit.com>]

On Mon, Sep 11, 2023 at 03:35:15PM +0200, David Disseldorp wrote:
> On Mon, 11 Sep 2023 12:07:07 +1000, Dave Chinner wrote:
> > On Sun, Sep 10, 2023 at 09:29:14PM -0400, Kent Overstreet wrote:
> > > What I've got in bcachefs-tools is a much thinner mapping from e.g.
> > > kthreads -> pthreads, block layer -> aio, etc.  
> > 
> > Right, and we've got that in userspace for XFS, too. If we really
> > cared that much about XFS-FUSE, I'd be converting userspace to use
> > ublk w/ io_uring on top of a port of the kernel XFS buffer cache as
> > the basis for a performant fuse implementation. However, there's a
> > massive amount of userspace work needed to get a native XFS FUSE
> > implementation up and running (even ignoring performance), so it's
> > just not a viable short-term - or even medium-term - solution to the
> > current problems.
> > 
> > Indeed, if you do a fuse->fs ops wrapper, I'd argue that lklfuse is
> > the place to do it so that there is a single code base that supports
> > all kernel filesystems without requiring anyone to support a
> > separate userspace code base. Requiring every filesystem to do their
> > own FUSE ports and then support them doesn't reduce the overall
> > maintenance overhead burden on filesystem developers....
> 
> LKL is still implemented as a non-mmu architecture. The only fs specific
> downstream change that lklfuse depends on is non-mmu xfs_buf support:
> https://lore.kernel.org/linux-xfs/1447800381-20167-1-git-send-email-octavian.purdila@intel.com/

That was proposed in 2015.

> Does your lklfuse enthusiasm here imply that you'd be willing to
> reconsider Octavian's earlier proposal for XFS non-mmu support?

8 years a long time, circumstances change and we should always be
open to changing our minds when presented with new circumstances
and/or evidence.

Context: back in 2015 I was in the middle of a significant revamp of
the kernel and userspace code - that was when the shared libxfs
codebase was new and being actively developed, along with a
significant rework of all the userspace shims.  One of the things
that I was looking at the time was pulling everything into userspace
via libxfs that was needed for a native XFS-FUSE implementation.
That project never got that far - maintainer burnout happened before
that ever became a reality.

In that context, lklfuse didn't really make a whole lot of sense for
providing userspace XFS support via fuse because a native FUSE
solution would be much better in most regards (especially
performance). Things have changed a whole lot since then. We have
less fs developers, we have a antagonistic, uncooperative testing
"community", we have more code and releases to support, etc.

If we go back to what I said earlier about the minimum requirements
for a "community supported filesystem", it was about needing three
things:

- mkfs and fsck coverage
- fstests support
- syzbot doesn't get run on it

Now reconsider lklfuse from this perspective. We have #1 for most
filesystems, #2 is pretty trivial, and #3 is basically "syzbot +
lklfuse > /dev/null"...

IOWs, we can largely validate that lklfuse doesn't eat your data
with relatively little extra effort. We can provide userspace with a
viable, supported mechanism for unprivileged mounts of untrusted
filesystem images that can't lead to kernel compromise. And,
largely, we retain control of the quality of the lklfuse
implementation because it's running the kernel code that we already
maintain and support.

Times change, circumstances change, and if we aren't willing to
change our minds because we need to solve the new challenges
presented to us then we should not be in decision making
positions....

Cheers,

Dave.
-- 
Dave Chinner
david@fromorbit.com