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

Date:   Tue, 14 May 2019 10:15:43 +0200
From:   Stefano Garzarella <sgarzare@...hat.com>
To:     netdev@...r.kernel.org, Stefan Hajnoczi <stefanha@...hat.com>,
        Dexuan Cui <decui@...rosoft.com>,
        Jorgen Hansen <jhansen@...are.com>
Cc:     "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: [RFC] vsock: proposal to support multiple transports at runtime

Hi guys,
I'm currently interested on implement a multi-transport support for VSOCK in
order to handle nested VMs.

As Stefan suggested me, I started to look at this discussion:
https://lkml.org/lkml/2017/8/17/551
Below I tried to summarize a proposal for a discussion, following the ideas
from Dexuan, Jorgen, and Stefan.


We can define two types of transport that we have to handle at the same time
(e.g. in a nested VM we would have both types of transport running together):

- 'host side transport', it runs in the host and it is used to communicate with
  the guests of a specific hypervisor (KVM, VMWare or HyperV)

  Should we support multiple 'host side transport' running at the same time?

- 'guest side transport'. it runs in the guest and it is used to communicate
  with the host transport


The main goal is to find a way to decide what transport use in these cases:
1. connect() / sendto()

	a. use the 'host side transport', if the destination is the guest
	   (dest_cid > VMADDR_CID_HOST).
	   If we want to support multiple 'host side transport' running at the
	   same time, we should assign CIDs uniquely across all transports.
	   In this way, a packet generated by the host side will get directed
	   to the appropriate transport based on the CID

	b. use the 'guest side transport', if the destination is the host
	   (dest_cid == VMADDR_CID_HOST)


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)

	b. use the 'guest side transport', if the socket is bound to local CID
	   different from the VMADDR_CID_HOST (guest CID get with
	   IOCTL_VM_SOCKETS_GET_LOCAL_CID), or it is bound to VMADDR_CID_ANY
	   (to be backward compatible).
	   Also in this case, we could define a new VMADDR_CID_LISTEN_FROM_HOST.

Thanks in advance for your comments and suggestions.

Cheers,
Stefano