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 11:13:46 +0800
From:	Zheng Liu <gnehzuil.liu@...il.com>
To:	Hannes Frederic Sowa <hannes@...essinduktion.org>
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?

Hi Hannes,

On Tue, Mar 18, 2014 at 02:21:20AM +0100, Hannes Frederic Sowa wrote:
> 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.

Thanks for your explanation.

> 
> > > 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. ;)

That sounds great!  But it might not satisfy our requirement.  If we use
AF_UNIX our program will not be deployed on two servers.  Meanwhile
AF_INET has been applied in our program to communicate with other
clients.  So DGRAM seems that it is not a good idea.  Now our program
needs a IPC mechansim that can commnucate between two servers and
provide a high performance when two processes are run on the same
server.  That is the reason why I am interested in TCP friends.  :)

Regards,
                                                - Zheng
--
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