netdev - Re: [RFC 00/10] NFS: add AF_VSOCK support to NFS client

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, 10 Jun 2015 14:09:26 -0400
From:	"J. Bruce Fields" <bfields@...ldses.org>
To:	Stefan Hajnoczi <stefanha@...hat.com>
Cc:	linux-nfs@...r.kernel.org,
	Anna Schumaker <anna.schumaker@...app.com>,
	Trond Myklebust <trond.myklebust@...marydata.com>,
	asias.hejun@...il.com, netdev@...r.kernel.org,
	Daniel Berrange <berrange@...hat.com>,
	"David S. Miller" <davem@...emloft.net>
Subject: Re: [RFC 00/10] NFS: add AF_VSOCK support to NFS client

On Wed, Jun 10, 2015 at 05:43:15PM +0100, Stefan Hajnoczi wrote:
> On Mon, Jun 08, 2015 at 05:02:47PM -0400, J. Bruce Fields wrote:
> > On Thu, Jun 04, 2015 at 05:45:43PM +0100, Stefan Hajnoczi wrote:
> > > The approach in this series
> > > ---------------------------
> > > AF_VSOCK stream sockets can be used for NFSv4.1 much in the same way as TCP.
> > > RFC 1831 record fragments divide messages since SOCK_STREAM semantics are
> > > present.  The backchannel shares the connection just like the default TCP
> > > configuration.
> > 
> > So the NFSv4 backchannel isn't handled for now, I assume.
> 
> Right, I did not touch nfs4_callback_up_net(), only
> nfs41_callback_up_net().
> 
> If I'm reading the code right NFSv4 uses a separate listen port for the
> backchannel instead of sharing the client's socket?

Right.

> This is possible to implement with AF_VSOCK but I have only tested
> NFSv4.1 so far.  Should I go ahead and do this?

Personally I'd make it a lower priority--I don't see why you can't make
4.1 a requirement for the new transport--but I'd be curious what others
have to say.

> > And I guess
> > NFSv2/v3 is out too thanks to rpcbind?  Which maybe is fine.
> 
> Yes, I ignored rpcbind and didn't test NFSv2/v3.
> 
> > Do we need an IETF draft or similar to document how NFS should work over
> > AF_VSOCK?
> 
> I am not familiar with the standards process but I came across a few
> places where it makes sense to have a standard:
> 
>  * SUNRPC netid for AF_VSOCK (currently "tcp", "udp", and others exist)
>  * The uaddr string format ("vsock:...")

Off the top of my head I can't remember where else that's used in the
protocol other than in setting up the 4.0 callback connection (and in
rpcbind).

>  * Use of RFC 1831 record fragments (just like TCP) over AF_VSOCK
>    SOCK_STREAM sockets

As far as I can tell, 1831 claims to be independent of any transport
protocol details: "The RPC protocol can be implemented on several
different transport protocols.  The RPC protocol does not care how a
message is passed from one process to another, but only with
specification and interpretation of messages."  And: "When RPC messages
are passed on top of a byte stream transport protocol (like TCP)"....
So perhaps there's nothing more to say here.

> These are all at the SUNRPC level rather than at the NFS protocol level.
> 
> Any idea who I need to talk to?

Anyay, if there is anything to be worked out, nfsv4@...f.org is the
place to go.

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