netdev - Re: [PATCH rfc] packet: zerocopy packet

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: <1417079412.18179.3@smtp.corp.redhat.com>
Date:	Thu, 27 Nov 2014 09:18:12 +0008
From:	Jason Wang <jasowang@...hat.com>
To:	"Michael S. Tsirkin" <mst@...hat.com>
Cc:	Willem de Bruijn <willemb@...gle.com>,
	Network Development <netdev@...r.kernel.org>,
	David Miller <davem@...emloft.net>,
	Eric Dumazet <eric.dumazet@...il.com>,
	Daniel Borkmann <dborkman@...hat.com>
Subject: Re: [PATCH rfc] packet: zerocopy packet_snd



On Thu, Nov 27, 2014 at 5:17 AM, Michael S. Tsirkin <mst@...hat.com> 
wrote:
> On Wed, Nov 26, 2014 at 02:59:34PM -0500, Willem de Bruijn wrote:
>>  > The main problem with zero copy ATM is with queueing disciplines
>>  > which might keep the socket around essentially forever.
>>  > The case was described here:
>>  > https://lkml.org/lkml/2014/1/17/105
>>  > and of course this will make it more serious now that
>>  > more applications will be able to do this, so
>>  > chances that an administrator enables this
>>  > are higher.
>>  
>>  The denial of service issue raised there, that a single queue can
>>  block an entire virtio-net device, is less problematic in the case 
>> of
>>  packet sockets. A socket can run out of sk_wmem_alloc, but a prudent
>>  application can increase the limit or use separate sockets for
>>  separate flows.
> 
> Socket per flow? Maybe just use TCP then?  increasing the limit
> sounds like a wrong solution, it hurts security.
> 
>>  > One possible solution is some kind of timer orphaning frags
>>  > for skbs that have been around for too long.
>>  
>>  Perhaps this can be approximated without an explicit timer by 
>> calling
>>  skb_copy_ubufs on enqueue whenever qlen exceeds a threshold value?
> 
> Hard to say. Will have to see that patch to judge how robust this is.

This could not work, consider if the threshold is greater than vring 
size
or vhost_net pending limit, transmission may still be blocked.

--
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