linux-kernel - Re: [fuse-devel] OSS Proxy Jack slave

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:	Wed, 09 Jun 2010 12:08:06 +0200
From:	Miklos Szeredi <miklos@...redi.hu>
To:	Tejun Heo <tj@...nel.org>
CC:	hmajxxlh@...bac.com, fuse-devel@...ts.sourceforge.net,
	mszeredi@...e.cz, linux-kernel@...r.kernel.org
Subject: Re: [fuse-devel] OSS Proxy Jack slave

On Sat, 05 Jun 2010, Tejun Heo wrote:
> Hello,
> 
> (cc'ing Miklos and mailing lists)
> 
> On 06/05/2010 10:50 AM, Mikael Bouillot wrote:
> > Just a quick question: have you reached some form of understanding
> > with Miklos Szeredi over the direct mmap in FUSE issue?
> > 
> > I've read the thread from February 2010, and though most of the
> > kernel material fly way over my head, I've got the general idea.
> > 
> > FUSD has had mmap support since around the time I started using
> > oss2jack, so I don't know exactly how many apps I use require it
> > (besides Quake3). I'll put a printf in my oss2jack's mmap() to
> > see what I'll be missing.
> > 
> > I could use a patched FUSE, but stopping to have to maintain a
> > piece of out-of-tree kernel code was The. Whole. Point. of
> > switching from FUSD to a CUSE-based system T_T
> 
> Miklos, any update on the mmap interface?

Sorry, got distracted by splice support on the fuse device.

I thought a bit about mmap in the last couple of days, and here's what
I came up with.  This week I'll take a stab at implementing some of
this (as a hack week project, let's say :).

First, I think server side mmap might be nice to have but not strictly
necessary.  I looked at osspd and it just memcopies in and out of the
mmaped ring buffer.  Replacing those memcopies with explicit syscalls
to get and put the data should work fine.  I doubt that the latency or
CPU overhead introduced by the syscalls would actually matter in
practice.

So we have the problem of how to do server initiated data transfer
to/from kernel buffers.  We could introduce the following
"notifications", which are initiated by the filesystem:

store request
 u64 nodeid
 u64 offset
 u32 size
 u32 padding
 data...

retrieve request:
 u64 request_id
 u64 nodeid
 u64 offset
 u32 size
 u32 padding

retrieve reply:
 u64 request_id
 data...

Notice the asymmetry, store doesn't need a reply but retrieve does.
Which is unfortunate as it makes it harder to impelent on both the
kernel side and the server side.

Next thing is how to deal with multiple buffers for each char device.
For the above to continue to work we need to make sure there's a
separate nodeid associated with each buffer.  The most general thing
would be if MMAP reply contained a nodeid which identified the buffer.

Do you see any issues with the above?

Thanks,
Miklos
--
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/