netdev - Re: [RFC 0/5] Introduce VM Sockets virtio transport

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, 28 Jun 2013 13:50:19 +0800
From:	Asias He <asias@...hat.com>
To:	Andy King <acking@...are.com>
Cc:	"Michael S. Tsirkin" <mst@...hat.com>, netdev@...r.kernel.org,
	kvm@...r.kernel.org, virtualization@...ts.linux-foundation.org,
	"David S. Miller" <davem@...emloft.net>,
	Dmitry Torokhov <dtor@...are.com>,
	Reilly Grant <grantr@...are.com>,
	Rusty Russell <rusty@...tcorp.com.au>,
	Jason Wang <jasowang@...hat.com>,
	Stefan Hajnoczi <stefanha@...il.com>,
	Gerd Hoffmann <kraxel@...hat.com>,
	Pekka Enberg <penberg@...nel.org>,
	Sasha Levin <sasha.levin@...cle.com>
Subject: Re: [RFC 0/5] Introduce VM Sockets virtio transport

On Thu, Jun 27, 2013 at 07:25:40PM -0700, Andy King wrote:
> Hi Michael,
> 
> > >            __u32 guest_cid;
> > 
> > Given that cid is like an IP address, 32 bit seems too
> > limiting. I would go for a 64 bit one or maybe even 128 bit,
> > so that e.g. GUIDs can be used there.
> 
> That's likely based on what vSockets uses, which is in turn based on
> what the VMCI device exposes (which is what vSockets was originally
> built on), so unfortunately it's too late to extend that type.
> However, that still allows just under 2^32 VMs per host (there are
> three reserved values).

Yes, 32 bit cid and port are defined by vSockets, we can not go for 64 bit
for virtio transport.

> > >            __u32   dst_port;
> > 
> > Ports are 32 bit? I guess most applications can't work with >16 bit.
> 
> As with the cid, the width of the port type comes from vSockets,
> which is what this plugs into.

Yes.

> > Also, why put cid's in all packets? They are only needed
> > when you create a connection, no? Afterwards port numbers
> > can be used.
> 
> The cid is present in DGRAM packets and STREAM _control_ packets
> (connection handshake, signal read/write and so forth).  I don't
> think the intent here is for it to be in STREAM _data_ packets,
> but Asias can clarify.

Virtio transport stream data packets are a bit different from how VMCI transport
handles them. In VMCI, a dedicated queue pairs is created for each
stream. In virtio, all the streams share the single virtqueue pairs.

On the recv path, we need the cid and port information from the packet
header to figure out which socket is responsible for the packet.

> > > Virtio VM socket connection creation:
> > > 1) Client sends VIRTIO_VSOCK_OP_REQUEST to server
> > > 2) Server reponses with VIRTIO_VSOCK_OP_NEGOTIATE to client
> > > 3) Client sends VIRTIO_VSOCK_OP_OFFER to server
> > > 4) Server responses with VIRTIO_VSOCK_OP_ATTACH to client
> > 
> > What's the reason for a 4 stage setup? Most transports
> > make do with 3.
> 
> I'm guessing that's also based on the original vSockets/VMCI
> implementation, where the NEGOTIATE/OFFER stages are used to
> negotiate the underlying transport buffer size (in VMCI, the
> queuepair that underlies a STREAM socket).  The virtio
> transport can probably use 3.

Right, I wanted to follow how VMCI transport does the connection setup.

We can drop the IRTIO_VSOCK_OP_ATTACH stage, and make the client into
SS_CONNECTED state once we get the VIRTIO_VSOCK_OP_NEGOTIATE pkt.

> Thanks!
> - Andy

-- 
Asias
--
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