linux-kernel - Re: [RFC PATCH] xfs: support for non-mmu architectures

Open Source and information security mailing list archives

Message-ID: <20151120152412.GC60886@bfoster.bfoster>
Date:	Fri, 20 Nov 2015 10:24:13 -0500
From:	Brian Foster <bfoster@...hat.com>
To:	Octavian Purdila <octavian.purdila@...el.com>
Cc:	Dave Chinner <david@...morbit.com>,
	Richard Weinberger <richard.weinberger@...il.com>,
	linux-fsdevel <linux-fsdevel@...r.kernel.org>,
	LKML <linux-kernel@...r.kernel.org>, xfs <xfs@....sgi.com>
Subject: Re: [RFC PATCH] xfs: support for non-mmu architectures

On Fri, Nov 20, 2015 at 04:26:28PM +0200, Octavian Purdila wrote:
> On Fri, Nov 20, 2015 at 2:58 AM, Dave Chinner <david@...morbit.com> wrote:
> > On Fri, Nov 20, 2015 at 12:54:02AM +0100, Richard Weinberger wrote:
> >> On Fri, Nov 20, 2015 at 12:24 AM, Dave Chinner <david@...morbit.com> wrote:
> >> > On Wed, Nov 18, 2015 at 12:46:21AM +0200, Octavian Purdila wrote:
> >> >> Naive implementation for non-mmu architectures: allocate physically
> >> >> contiguous xfs buffers with alloc_pages. Terribly inefficient with
> >> >> memory and fragmentation on high I/O loads but it may be good enough
> >> >> for basic usage (which most non-mmu architectures will need).
> >> >
> >> > Can you please explain why you want to use XFS on low end, basic
> >> > non-MMU devices? XFS is a high performance, enterprise/HPC level
> >> > filesystem - it's not a filesystem designed for small IoT level
> >> > devices - so I'm struggling to see why we'd want to expend any
> >> > effort to make XFS work on such devices....
> >>
> >> The use case is the Linux Kernel Library:
> >> https://lkml.org/lkml/2015/11/3/706
> >>
> >> Using LKL and fuse you can mount any kernel filesystem using fuse
> >> as non-root.
> >
> > IOWs, because we said no to unprivileged mounts, instead the
> > proposal is to linking all the kernel code into userspace so you can
> > do unprivielged mounts that way?
> >
> 
> LKL's goal is to make it easy for various applications to reuse Linux
> kernel code instead of re-implementing it. Mounting filesystem images
> is just one of the applications.
> 
> > IOWs, you get to say "it secure because it's in userspace" and leave
> > us filesystem people with all the shit that comes with allowing
> > users to mount random untrusted filesystem images using code that
> > was never designed to allow that to happen?
> >
> 
> It is already possible to mount arbitrary filesystem images in
> userspace using VMs . LKL doesn't change that, it just reduces the
> amount of dependencies you need to do so.
> 

Perhaps a dumb question, but I'm not quite putting 2+2 together here.
When I see nommu, I'm generally thinking hardware characteristics, but
we're talking about a userspace kernel library here. So can you
elaborate on how this relates to nommu? Does this library emulate kernel
mechanisms in userspace via nommu mode or something of that nature?
Thanks.

Brian

> Could you expand of what burden does this use-case put on fs
> developers? I am sure that, if needed, we can put restrictions in LKL
> to avoid that.
> 
> _______________________________________________
> xfs mailing list
> xfs@....sgi.com
> http://oss.sgi.com/mailman/listinfo/xfs
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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