netdev - Re: [PATCH v2 0/5] Add virtio transport for AF

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]

Message-ID: <20151209023804.GC22280@stefanha-x1.localdomain>
Date:	Wed, 9 Dec 2015 10:38:04 +0800
From:	Stefan Hajnoczi <stefanha@...hat.com>
To:	"Michael S. Tsirkin" <mst@...hat.com>
Cc:	kvm@...r.kernel.org, Matt Benjamin <mbenjamin@...hat.com>,
	Christoffer Dall <christoffer.dall@...aro.org>,
	netdev@...r.kernel.org, matt.ma@...aro.org,
	virtualization@...ts.linux-foundation.org
Subject: Re: [PATCH v2 0/5] Add virtio transport for AF_VSOCK

On Fri, Dec 04, 2015 at 09:45:04AM +0200, Michael S. Tsirkin wrote:
> On Wed, Dec 02, 2015 at 02:43:58PM +0800, Stefan Hajnoczi wrote:
> > 1. The 3-way handshake isn't necessary over a reliable transport (virtqueue).
> >    Spoofing packets is also impossible so the security aspects of the 3-way
> >    handshake (including syn cookie) add nothing.  The next version will have a
> >    single operation to establish a connection.
> 
> It's hard to discuss without seeing the details, but we do need to
> slow down guests that are flooding host with socket creation requests.
> The handshake is a simple way for hypervisor to defer
> such requests until it has resources without
> breaking things.

I'll send an updated virtio-vsock device specification so we can discuss
it.

VMCI simply uses sk->sk_max_ack_backlog in
net/vmw_vsock/vmci_transport.c.  If backlog (from listen(2)) is maxed
out then the connection is refused.

The same would work for virtio-vsock and there is no advantage to the
3-way handshake.

> > 2. Credit-based flow control doesn't work for SOCK_DGRAM since multiple clients
> >    can transmit to the same listen socket.  There is no way for the clients to
> >    coordinate buffer space with each other fairly.  The next version will drop
> >    credit-based flow control for SOCK_DGRAM and only rely on best-effort
> >    delivery.  SOCK_STREAM still has guaranteed delivery.
> 
> I suspect in the end we will need a measure of fairness even
> if you drop packets. And recovering from packet loss is
> hard enough that not many applications do it correctly.
> I suggest disabling SOCK_DGRAM for now.

I'm not aware of a SOCK_DGRAM user at this time.  Will disable it for
now.

Download attachment "signature.asc" of type "application/pgp-signature" (474 bytes)