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>] [day] [month] [year] [list]
Date:	Fri, 17 Jun 2011 08:15:02 -0500
From:	Brandon Black <blblack@...il.com>
To:	netdev@...r.kernel.org
Cc:	Arnaldo Carvalho de Melo <acme@...hat.com>, anton@...ba.org
Subject: Re: [PATCH] net: Add sendmmsg socket system call

Re: the patch in http://lists.openwall.net/netdev/2011/05/03/12 ,
which is now in the 3.0-rc kernels

I was wondering if would it be possible / valid to add support to
sendmmsg() for skipping packets with a zero msg_iovlen?  The use-case
I'm think of here is a daemon that's basically looping on recvmmsg() +
sendmmsg() to cut overhead.  The simplest userspace approach in this
sort of case is to re-use the same mmsg_hdr and set of iov's for both
recvmmsg() and sendmmsg().

Consider this scenario though: It may, for example, receive 8 packets,
parse them in userspace, decide packet #5 is malformed, and then wish
to respond only to packets 1-4,6-8.  However, in order to drop a
response packet from the set with the current sendmmsg()
implementation, the userspace code would have to shift all of the
mmsg_hdr entries down to close the gaps where no response was desired.
 If sendmmsg() had code to simply skip the underlying sendmsg() on
msg_iovlen = 0, it becomes a lot simpler to handle this case.  sendmsg
with a msg_iovlen of zero currently sends a packet with no data (just
UDP headers in the UDP case) it seems.

The arguments against this would be that some applications may have a
use for sending zero-data-bytes packets via this mechanism today
(although there's the alternate path for this with msg_iovlen = 1 and
a zero length for the actual iov within), and the overhead of adding
another branch in the sendmmsg() code.  I suppose there's a middle
route too, where we add a custom flags for sendmmsg() to turn on this
behavior, and leave the default at today's behavior.

Anyone have any thoughts for/against this idea?  Leaving this alone in
the kernel and doing the shifting in userspace isn't too bad a
solution either, but if nobody has a problem with patching in the
"skip on msg_iovlen == 0" behavior it does make the userspace code
cleaner and simpler.

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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ