netdev - Re: [PATCH] tun: orphan an skb on tx

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]

Message-ID: <1422797630.11044.32.camel@infradead.org>
Date:	Sun, 01 Feb 2015 13:33:50 +0000
From:	David Woodhouse <dwmw2@...radead.org>
To:	"Michael S. Tsirkin" <mst@...hat.com>
Cc:	Herbert Xu <herbert@...dor.apana.org.au>,
	Eric Dumazet <eric.dumazet@...il.com>,
	Jan Kiszka <jan.kiszka@...mens.com>,
	"David S. Miller" <davem@...emloft.net>,
	Paul Moore <paul.moore@...com>,
	"netdev@...r.kernel.org" <netdev@...r.kernel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	qemu-devel <qemu-devel@...gnu.org>
Subject: Re: [PATCH] tun: orphan an skb on tx

On Sun, 2015-02-01 at 14:26 +0200, Michael S. Tsirkin wrote:
> > When I run over the VPN, netperf thinks it sent 2½ times the amount of
> > TX traffic.
> 
> At some level, it's expected: netperf's manual actually says:
> 	A UDP_STREAM test has no end-to-end flow control - UDP provides none and
> 	neither does netperf. However, if you wish, you can configure netperf
> 	with --enable-intervals=yes to enable the global command-line -b and -w
> 	options to pace bursts of traffic onto the network.

True, but UDP is just a canary for other protocols here. We *should* be
able to keep track of the packets before they even leave the box, and
know that we haven't even managed to send them. Even if we know it's a
datagram protocol and it's potentially going to be dropped in transit
later.

Of course, now I'm looking closely at the path these packets take to
leave the box, it starts to offend me that they're being passed up to
userspace just to encrypt them (as DTLS or ESP) and then send them back
down to the kernel on a UDP socket. The kernel already knows how to
{en,de}crypt ESP, and do the sequence number checking on incoming
packets.

I'm wondering if we bypass userspace in that case somehow — let
userspace negotiate the encryption and connect the UDP socket, then just
pass the socket fd and the parameters to the kernel so that incoming
packets are decrypted and 'received' on the tun device, and outgoing
packets on the tun device are encrypted and sent out on the UDP socket. 

The performance isn't too much of an issue for a VPN *client* in
practice, but we have a server implementation too which would probably
benefit quite well from such an offload facility.

If I were to look at such a thing, would it provoke screams of horror? 

-- 
dwmw2

Download attachment "smime.p7s" of type "application/x-pkcs7-signature" (5745 bytes)