linux-kernel - Re: [PATCH 4/4] FUSE: implement direct mmap

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:	Sat, 04 Jul 2009 20:14:32 +0900
From:	Tejun Heo <tj@...nel.org>
To:	Miklos Szeredi <miklos@...redi.hu>
CC:	linux-kernel@...r.kernel.org, fuse-devel@...ts.sourceforge.net,
	akpm@...ux-foundation.org, npiggin@...e.de
Subject: Re: [PATCH 4/4] FUSE: implement direct mmap

Hello, Miklos.

Miklos Szeredi wrote:
>> Simlar thing can be done by letting the kernel part of fuse keep track
>> of mapped pages using server provided page IDs and letting the server
>> determine sharing or creation of pages and communicate it to the
>> kernel part.  It would require more code but the interface should be
>> less convoluted and more flexible.  Is this what you have in mind?
> 
> Something like that.  In fact we could possibly allow even sharing the
> pages with userspace, similarly to how drivers do it with the
> hardware.

This was possible with the original implementation.  Hmmm... we'll
need some sort of filehandle to represent the address space one way or
the other.

> Afaics sound drivers now map the dma memory with remap_pfn_range().
> Similary we could allocate a chunk of non-swapabble kernel memory on
> request from the userspace server and map its pages using this trick
> to both the server's and the client's address space.
> 
> This is still sort of OSSP specific, I don't see clearly how it could
> be made more generic.

Using non-swappable memory would be fine for most device emulations
but mapping large amount of pages would be problematic.  Hmmm... this
is difficult.  It's a compromise among flexibility, scalability and
code complexity.

>>>> mmap request is handled in two steps.  MMAP first queries the server
>>>> whether it wants to share the mapping with an existing one or create a
>>>> new one, and if so, with which flags.  MMAP_COMMIT notifies the server
>>>> the result of mmap and if successful the fd the server can use to
>>>> access the mmap region.
>>> And you might have noticed I'm not a big fan of these three way handshake
>>> messages ;)
>> Believe it or not, I'm not particularly big fan of it either.  I just
>> couldn't think of anything better at the time.  :-)
> 
> A better scheme would be to assume that MMAP is successful, and if
> there's an error, send a MUNMAP request.  That way the normal case is
> simpler and there's no need for an extra message type.

The reason why the second stage was necessary was because the fd needs
to be communicated back to the server.  The kernel doesn't know
whether the server wants to share an existing fd or create a new one
so the MMAP queries that and MMAP_COMMIT communicates newly created fd
if necessary.  What can be done is to always create a new fd and let
the server override it if it wants the map to be shared and then the
kernel can kill the unused fd.

Thanks.

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