netdev - Re: [Pv-drivers] [PATCH 0/6] VSOCK for Linux upstreaming

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] [day] [month] [year] [list]

Date:	Thu, 6 Dec 2012 07:28:13 -0800 (PST)
From:	Andy King <acking@...are.com>
To:	Anthony Liguori <aliguori@...ibm.com>
Cc:	pv-drivers@...are.com, netdev@...r.kernel.org,
	linux-kernel@...r.kernel.org,
	virtualization@...ts.linux-foundation.org,
	gregkh@...uxfoundation.org, David Miller <davem@...emloft.net>,
	georgezhang@...are.com,
	Benjamin Herrenschmidt <benh@...nel.crashing.org>,
	Gerd Hoffmann <kraxel@...hat.com>
Subject: Re: [Pv-drivers] [PATCH 0/6] VSOCK for Linux upstreaming

Hi Anthony,

> This was already done in a hypervisor neutral way using virtio:
> 
> http://lists.openwall.net/netdev/2008/12/14/8
> 
> The concept was Nacked and that led to the abomination of
> virtio-serial.  If an address family for virtualization is on the
> table, we should reconsider AF_VMCHANNEL.

I finally had a look at your patch.  Please correct me if I'm wrong,
but it seems that the peer of an AF_VMCHANNEL connection is a virtio
channel inside the hypervisor, i.e., the other end is _not_ sockets,
right?

That's quite a bit different from vSockets, where both sides use the
socket interface, even within the VMX process in our hypervisor.  We
also intend for arbitrary host processes -- those outside the
hypervisor -- to use it via the sockets interface.  We have shipping
applications that do just that, where communication is between a guest
process and a host service, with both sides using the standard socket
API but with the vSockets address family.  We also encourage people to
write such VM-to-host applications, and we've been shipping the
vSockets header in our host-side products to allow people to do just
that.

So I think in that sense vSockets is somewhat more general, and we'd
obviously prefer to go with our socket family and address structure
if LKML is open to something like this.

Thanks!
- Andy

PS I realize we still owe LKML a spec for the vSockets protocol.
--
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