netdev - Re: We have FUSE, could we have NUSE ?

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:	Thu, 8 Mar 2007 08:57:54 -0500
From:	"John W. Linville" <linville@...driver.com>
To:	Matti Aarnio <matti.aarnio@...iler.org>
Cc:	netdev@...r.kernel.org
Subject: Re: We have FUSE, could we have NUSE ?

On Thu, Mar 08, 2007 at 12:53:20PM +0200, Matti Aarnio wrote:

> The aim of "NUSE" from applications point of view would be to be
> indistinguishable from kernel implemented services.
> 
> What would this require from the service hook side ?
>   - Socket read and write can be trivialishly done
>     like a pipe in between processes
>   - Somehow pass ancilliary data for:
>      - socket, socketpair
>      - connect, bind
>      - accept
>      - listen
>      - getpeername, getsockname
>      - sendto, send
>      - recvfrom, revc
>      - setsockopt, getsockopt
>   - poll / epoll ?

It is certainly possible to do this by implementing your own socket
family.  I did such a thing as infrastructure for talking to network
processors in a former life.  In that case the socket code was talking
to other kernel code, but getting it to coordinate w/ userland is
largely a SMOP.  You might consider using (generic?) netlink for
your backend communications to the userland daemon.  In addition,
there might be other kernel extensions required (e.g. dynamic socket
family allocation?).

> Death of the protocol engine process must also destroy all existing
> sockets of the served protocol type, and refuse to generate any new
> sockets of the type.

That's up to you (or whomever implements the kernel code).

> The first protocol that I have in mind to implement on top of this service
> does not need very much of local sockets.
> (It is called "STANAG-5066" - radio data communication on HF frequencies.
> Specification is written by NATO, thus "STANAG", but my use plans for it
> are more along the AX.25 ham-radio things.)

Nifty. :-)

John
-- 
John W. Linville
linville@...driver.com
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html