netdev - Re: [RFC] vsock: proposal to support multiple transports at runtime

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:   Mon, 3 Jun 2019 12:49:48 +0200
From:   Stefano Garzarella <sgarzare@...hat.com>
To:     Jorgen Hansen <jhansen@...are.com>
Cc:     Stefan Hajnoczi <stefanha@...hat.com>,
        "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
        Dexuan Cui <decui@...rosoft.com>,
        "David S. Miller" <davem@...emloft.net>,
        Vishnu DASA <vdasa@...are.com>,
        "K. Y. Srinivasan" <kys@...rosoft.com>,
        Haiyang Zhang <haiyangz@...rosoft.com>,
        Stephen Hemminger <sthemmin@...rosoft.com>,
        Sasha Levin <sashal@...nel.org>
Subject: Re: [RFC] vsock: proposal to support multiple transports at runtime

On Fri, May 31, 2019 at 09:24:49AM +0000, Jorgen Hansen wrote:
> On 30 May 2019, at 13:19, Stefano Garzarella <sgarzare@...hat.com> wrote:
> > 
> > On Tue, May 28, 2019 at 04:01:00PM +0000, Jorgen Hansen wrote:
> >>> On Thu, May 23, 2019 at 04:37:03PM +0100, Stefan Hajnoczi wrote:
> >>>> On Tue, May 14, 2019 at 10:15:43AM +0200, Stefano Garzarella wrote:
> > 
> >>>>> 
> >>>>> 
> >>>>> 2. listen() / recvfrom()
> >>>>> 
> >>>>>    a. use the 'host side transport', if the socket is bound to
> >>>>>       VMADDR_CID_HOST, or it is bound to VMADDR_CID_ANY and there is no
> >>>>>       guest transport.
> >>>>>       We could also define a new VMADDR_CID_LISTEN_FROM_GUEST in order to
> >>>>>       address this case.
> >>>>>       If we want to support multiple 'host side transport' running at the
> >>>>>       same time, we should find a way to allow an application to bound a
> >>>>>       specific host transport (e.g. adding new VMADDR_CID_LISTEN_FROM_KVM,
> >>>>>       VMADDR_CID_LISTEN_FROM_VMWARE, VMADDR_CID_LISTEN_FROM_HYPERV)
> >>>> 
> >>>> Hmm...VMADDR_CID_LISTEN_FROM_KVM, VMADDR_CID_LISTEN_FROM_VMWARE,
> >>>> VMADDR_CID_LISTEN_FROM_HYPERV isn't very flexible.  What if my service
> >>>> should only be available to a subset of VMware VMs?
> >>> 
> >>> You're right, it is not very flexible.
> >> 
> >> When I was last looking at this, I was considering a proposal where
> >> the incoming traffic would determine which transport to use for
> >> CID_ANY in the case of multiple transports. For stream sockets, we
> >> already have a shared port space, so if we receive a connection
> >> request for < port N, CID_ANY>, that connection would use the
> >> transport of the incoming request. The transport could either be a
> >> host->guest transport or the guest->host transport. This is a bit
> >> harder to do for datagrams since the VSOCK port is decided by the
> >> transport itself today. For VMCI, a VMCI datagram handler is allocated
> >> for each datagram socket, and the ID of that handler is used as the
> >> port. So we would potentially have to register the same datagram port
> >> with all transports.
> > 
> > So, do you think we should implement a shared port space also for
> > datagram sockets?
> 
> Yes, having the two socket types work the same way seems cleaner to me. We should at least cover it in the design.
> 

Okay, I'll add this point on a v2 of this proposal!

> > For now only the VMWare implementation supports the datagram sockets,
> > but in the future we could support it also on KVM and HyperV, so I think
> > we should consider it in this proposal.
> 
> So for now, it sounds like we could make the VMCI transport the default transport for any host side datagram socket, then.
> 

Yes, make sense.

> >> 
> >> The use of network namespaces would be complimentary to this, and
> >> could be used to partition VMs between hypervisors or at a finer
> >> granularity. This could also be used to isolate host applications from
> >> guest applications using the same ports with CID_ANY if necessary.
> >> 
> > 
> > Another point to the netns support, I'll put it in the proposal (or it
> > could go in parallel with the multi-transport support).
> > 
> 
> It should be fine to put in the proposal that we rely on namespaces to provide this support, but pursue namespaces as a separate project.

Sure.

I'll send a v2 adding all the points discussed to be sure that we are
aligned. Then I'll start working on it if we agree on the proposal.

Thanks,
Stefano