netdev - Re: Add a SOCK_DESTROY operation to close sockets from userspace

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]

Message-ID: <1447949964.22599.220.camel@edumazet-glaptop2.roam.corp.google.com>
Date:	Thu, 19 Nov 2015 08:19:24 -0800
From:	Eric Dumazet <eric.dumazet@...il.com>
To:	David Miller <davem@...emloft.net>
Cc:	zenczykowski@...il.com, lorenzo@...gle.com,
	hannes@...essinduktion.org, stephen@...workplumber.org,
	netdev@...r.kernel.org, edumazet@...gle.com, ek@...gle.com,
	dtor@...gle.com
Subject: Re: Add a SOCK_DESTROY operation to close sockets from userspace

On Thu, 2015-11-19 at 10:48 -0500, David Miller wrote:
> At least if they do it this way, and someone claims that Linux TCP
> behaves outside the spec or improperly, it's not directly because of
> any code I am responsible for.
> 
> That's the difference, and frankly an important one to me.
> 
> If I'm going to give userspace a direct tool by which to do things,
> then it's suddenly my responsibility and my problem.

Here is the thing :

- Android powered phones and devices have a similar code since 2008.
There is _no_ way they can avoid having this functionality.

Every-time I make a change in linux TCP stack, this code breaks, and
this a  real pain because Android changes need to be carried over to
vendors.

I worked closely with Lorenzo, removing the ugly code Android had, and
proposed an implementation based on inet_diag.

We have a clear business case here, and I would like we find a solution.

Having this code in upstream kernel will save me time and energy to deal
with real issues and improvements, not with bugs opened by Android
engineers 9 months after I did changes in upstream kernels.

Having comments like "look, just implement application keepalives" is
not going to work [1][2]. This is terrible, and show lack of
understanding of the problem. We are not dealing with DC communications
here. (I wish !)

We (TCP stack) compete with QUIC, based on UDP, which has no issues like
that. We need to allow TCP sessions being signaled of a non temporary
network disruption.

[1] Phones are very often in very polluted radio environments.

  I remember the terrible wifi we had during Linux Kernel Summit in
Chicago, where ping had more than 40 seconds delay.

Here the network manager can avoid this 40 seconds penalty.

[2] Taking air time to send keepalive(s) and receive their answers is
going to make all radio providers shout really loud. They are already
installing stupid proxies filtering/compressing ACK messages and
breaking TCP clocking.

Please add

Signed-off-by: Eric Dumazet <edumazet@...gle.com>

Please wait one month for people submitting a working alternative,
I am fine with it as long it is upstream.

Thanks.

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