svn commit: r334719 - in head: cddl/lib/libdtrace lib/libc/sys sys/kern sys/netinet sys/netinet6 sys/sys

Shawn Webb shawn.webb at hardenedbsd.org
Thu Jun 7 14:13:49 UTC 2018


On Wed, Jun 06, 2018 at 03:45:57PM +0000, Sean Bruno wrote:
> Author: sbruno
> Date: Wed Jun  6 15:45:57 2018
> New Revision: 334719
> URL: https://svnweb.freebsd.org/changeset/base/334719
> 
> Log:
>   Load balance sockets with new SO_REUSEPORT_LB option.
>   
>   This patch adds a new socket option, SO_REUSEPORT_LB, which allow multiple
>   programs or threads to bind to the same port and incoming connections will be
>   load balanced using a hash function.
>   
>   Most of the code was copied from a similar patch for DragonflyBSD.
>   
>   However, in DragonflyBSD, load balancing is a global on/off setting and can not
>   be set per socket. This patch allows for simultaneous use of both the current
>   SO_REUSEPORT and the new SO_REUSEPORT_LB options on the same system.
>   
>   Required changes to structures:
>   Globally change so_options from 16 to 32 bit value to allow for more options.
>   Add hashtable in pcbinfo to hold all SO_REUSEPORT_LB sockets.
>   
>   Limitations:
>   As DragonflyBSD, a load balance group is limited to 256 pcbs (256 programs or
>   threads sharing the same socket).
>   
>   This is a substantially different contribution as compared to its original
>   incarnation at svn r332894 and reverted at svn r332967.  Thanks to rwatson@
>   for the substantive feedback that is included in this commit.
>   
>   Submitted by:	Johannes Lundberg <johalun0 at gmail.com>
>   Obtained from:	DragonflyBSD
>   Relnotes:	Yes
>   Sponsored by:	Limelight Networks
>   Differential Revision:	https://reviews.freebsd.org/D11003

Hey Sean,

This is a rather interesting and useful feature. Thank you for
committing it. It seems there are some security trade-offs being made
for applications that opt-in to this feature: third-party
applications, potentially malicious, could bind to the port.

I wonder if we could prevent malicious abuse of this feature by
introducing a random cookie. When a developer sets this option, the
developer must specify a random value as a cookie. Applications who
want to share the port, then, must also specify the cookie (perhaps
via another socket option?).

What are your thoughts? I'm CC'ing Johannes to get his thoughts as
well.

Thanks,

-- 
Shawn Webb
Cofounder and Security Engineer
HardenedBSD

Tor-ified Signal:    +1 443-546-8752
Tor+XMPP+OTR:        lattera at is.a.hacker.sx
GPG Key ID:          0x6A84658F52456EEE
GPG Key Fingerprint: 2ABA B6BD EF6A F486 BE89  3D9E 6A84 658F 5245 6EEE
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.freebsd.org/pipermail/svn-src-head/attachments/20180607/feae0a4f/attachment.sig>


More information about the svn-src-head mailing list