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

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]

Date:	Fri, 20 Nov 2015 16:26:28 +0200
From:	Octavian Purdila <octavian.purdila@...el.com>
To:	Dave Chinner <david@...morbit.com>
Cc:	Richard Weinberger <richard.weinberger@...il.com>,
	xfs <xfs@....sgi.com>,
	linux-fsdevel <linux-fsdevel@...r.kernel.org>,
	LKML <linux-kernel@...r.kernel.org>
Subject: Re: [RFC PATCH] xfs: support for non-mmu architectures

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.

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.
--
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/