linux-kernel - Re: Unix sockets via TCP on localhost: is TCP slower?

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:	Fri, 14 Nov 2008 11:37:11 +0100
From:	Bernd Petrovitsch <bernd@...mix.at>
To:	Olaf van der Spek <olafvdspek@...il.com>
Cc:	David Miller <davem@...emloft.net>, jrm8005@...il.com,
	linux-kernel@...r.kernel.org
Subject: Re: Unix sockets via TCP on localhost: is TCP slower?

On Fri, 2008-11-14 at 10:09 +0100, Olaf van der Spek wrote:
> On Fri, Nov 14, 2008 at 9:56 AM, David Miller <davem@...emloft.net> wrote:
> >> Why would you use windowing, ACKs, flow control and encapsulation on localhost?
> >
> > So that you could firewall, shape, redirect, and make other
> > modifications to the traffic, as well as see it in tcpdumps.  That's
> > the power of Linux, and yes people do this stuff and yes people do
> > want these features to work over loopback.

ACK. Some people even patch their distributions init.d scripts so that
you have aliases (127.0.0.2 and so on) on the loopback interface. And
I'm not even in the simulation world where this probably comes erally
handy.
So as long as "lo" behaves as as normal network interface (with iptables
and whatever is available for eth, br, ...) with an IP address, any
tuning can be done.

> >> I expected the kernel to copy data directly from user-space of the
> >> sending process to a kernel buffer of the receiving process, much like
> >> UNIX sockets.
> >
> > Then all of the above features and debugging facilities go away.
> 
> So instead the recommendation is for all apps to support both TCP and
> Unix sockets?

Of course. That is simple (actually trivial IMO) and standard practice.

> If you then use Unix sockets, you still lose all of those facilities
> and as a bonus, your apps are more complex.

If your (network) app has config abilities for the IP address, the
complexity two either add two new fields (select AF_INET or AF_UNIX, a
path for AF_UNIX) or simply parse the "IP address" and if it's a path,
use AF_UNIX is neglectable.
So please *show* the complexity in adding
- very few config parameters,
- a if() somewhere, and
- the proper initialization of a "struct sockaddr_un".
Actually I see (and use) AF_UNIX as "I have an network app and it's
plain simply faster for local clients than AF_INET".

And the IMNSHO added complexity - which you fail to mention - in the
whole system (including the user) is to deal with "bug reports" like 'if
I change the IP address from 127.0.0.1 to $SOMETHING_ELSE, it behaves
quite different' or 'if I use eth0, it works, if I use "lo" not' *and*
vice versa (because the user usually doesn't know what's really
happening down below just above the TCP/IP stack) of course and similar
"weird" problems.
Or do you like apps where the documentation (and the app checks it if
you are lucky - or some feature just doesn't work) say that it can't be
used on "lo" because $FEATURE is not available there.

You plain simply violate the rule to avoid the (most) unexpected.

> I'd prefer a switch that could be enabled to use such a shortcut for TCP.
> Firewalls should still work mostly (on connect), redirect would still work.

Show numbers and propose a (tested) patch.

	Bernd
-- 
Firmix Software GmbH                   http://www.firmix.at/
mobil: +43 664 4416156                 fax: +43 1 7890849-55
          Embedded Linux Development and Services

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/