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

[Kent Overstreet <kent.overstreet@linux.dev>]

On Sun, Sep 10, 2023 at 07:26:26PM +0200, Geert Uytterhoeven wrote:
> On Sun, Sep 10, 2023 at 6:35 PM Kent Overstreet
> <kent.overstreet@linux.dev> wrote:
> > On Sun, Sep 10, 2023 at 10:19:30AM +0200, Geert Uytterhoeven wrote:
> > > On Sun, Sep 10, 2023 at 12:42 AM Kent Overstreet
> > > <kent.overstreet@linux.dev> wrote:
> > > > On Sat, Sep 09, 2023 at 08:50:39AM -0400, James Bottomley wrote:
> > > > > So why can't we figure out that easier way? What's wrong with trying to
> > > > > figure out if we can do some sort of helper or library set that assists
> > > > > supporting and porting older filesystems. If we can do that it will not
> > > > > only make the job of an old fs maintainer a lot easier, but it might
> > > > > just provide the stepping stones we need to encourage more people climb
> > > > > up into the modern VFS world.
> > > >
> > > > What if we could run our existing filesystem code in userspace?
> > > >
> > > > bcachefs has a shim layer (like xfs, but more extensive) to run nearly
> > > > the entire filesystem - about 90% by loc - in userspace.
> > > >
> > > > Right now this is used for e.g. userspace fsck, but one of my goals is
> > > > to have the entire filesystem available as a FUSE filesystem. I'd been
> > > > planning on doing the fuse port as a straight fuse implementation, but
> > > > OTOH if we attempted a sh vfs iops/aops/etc. -> fuse shim, then we would
> > > > have pretty much everything we need to run any existing fs (e.g.
> > > > reiserfs) as a fuse filesystem.
> > > >
> > > > It'd be a nontrivial project with some open questions (e.g. do we have
> > > > to lift all of bufferheads to userspace?) but it seems worth
> > > > investigating.
> > >
> > >   1. https://xkcd.com/1200/ (not an exact match, but you should get the idea),
> > >   2. Once a file system is removed from the kernel, would the user space
> > >      implementation be maintained better?
> >
> > This would be for the filesystems that aren't getting maintained and
> > tested, to eliminate accidental breakage from in-kernel refactoring and
> > changing of APIs.
> >
> > Getting that code out of the kernel would also greatly help with
> > security concerns.
> 
> OK, xkcd 1200 it is...

A fuse filesystem process can be restricted to only having access to the
device the filesystem is on.

Not so if it's running in the kernel...