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, 27 Jun 2013 19:25:40 -0700 (PDT)
From:	Andy King <acking@...are.com>
To:	"Michael S. Tsirkin" <mst@...hat.com>
Cc:	Asias He <asias@...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

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

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

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

Thanks!
- Andy
--
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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ