netdev - Re: What's the status of TCP friends?

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]

Date:	Tue, 18 Mar 2014 02:21:20 +0100
From:	Hannes Frederic Sowa <hannes@...essinduktion.org>
To:	Zheng Liu <gnehzuil.liu@...il.com>
Cc:	Eric Dumazet <eric.dumazet@...il.com>,
	netdev <netdev@...r.kernel.org>, Li Yu <bingtian.ly@...bao.com>,
	"David S. Miller" <davem@...emloft.net>,
	Eric Dumazet <edumazet@...gle.com>,
	Bruce Brutus Curtis <brutus@...gle.com>,
	Weiping Pan <panweiping3@...il.com>, tmorvai@...il.com
Subject: Re: What's the status of TCP friends?

On Mon, Mar 17, 2014 at 11:16:05AM +0800, Zheng Liu wrote:
> On Sun, Mar 16, 2014 at 07:03:39AM -0700, Eric Dumazet wrote:
> > On Sun, 2014-03-16 at 17:07 +0800, Zheng Liu wrote:
> > > Hi all,
> > > 
> > > Until now the TCP friends patch set doesn't be applied.  Now what's the
> > > status of TCP friends?  Is it applicable to be merged into upstream
> > > kernel?  Any problem that needs to be fixed?  Please let me know if I
> > > can help.
> > 
> > Well, last attempts showed that while the idea sounded cool,
> > implementation opened many races and added quite a lot of complexity in
> > fast path.
> 
> Thanks for letting me know the current status of this patch set.
> 
> > 
> > We have AF_UNIX with a lot of problems in it, do we really want to bring
> > these AF_UNIX problems to AF_INET ?
> 
> Please bear with me because I am a newbie.  Out of curiosity, what's the
> problem in AF_UNIX?

AFAIK AF_UNIX/SOCK_STREAM is fine.

I currently know about two problems with AF_UNIX datagram modes:

1) Not correclty handling socket receive buffer limits. SOCK_DGRAM simply
   relies on the sending window only and socket receive queue is only limited
   by the number of packets enqueued. A DoS against another UNIX/DGRAM server
   is possible by not freeing its sending window if the client doesn't simply
   pick up its packets.

2) POLLOUT handling seems a bit messed up. This problem was reported by Tamas
   Morvai. We simply trigger POLLOUT too often thus waking up the sending side
   unnecessarily.

Patch for 1) was rightfully rejected because it could easily break
backwards compatibility.

There were some ideas floating around which I discussed with Tamas but
nothing definite for 2), as I got stuck to work on 1) and I am still
unsure what side-effects could have the needed removal of the per-packet
socket-receive limit, which seems to be needed for solving 2). The total
amount of memory in use by AF_UNIX/DGRAM sockets would be limited by
the sending buffers and rlimits, but it still seems unwise to do so.

Also solving 2) could make problems regarding backwards-compatibility.

> > I would rather spend time on AF_UNIX if it doesn't fit your needs right
> > now, or consider jumping to KDBUS modern design.
> > 
> > Using AF_INET for IPC is poor choice.
> 
> The reason why we use AF_INET for IPC rather than use AF_UNIX is that we
> have two applications that need to communicate with each other.  They
> could be deployed on the same server or different servers.  So obviously
> if we use AF_INET, we just need to indicate a IP address in config file.
> That sounds rational and maintainable for our operation team.

As soon as we are allowed to silently drop packets in AF_UNIX/DGRAM some
problems would vanish, too. ;)

Greetings,

  Hannes

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