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: <1447952902.2049284.444501617.7C422D07@webmail.messagingengine.com>
Date:	Thu, 19 Nov 2015 18:08:22 +0100
From:	Hannes Frederic Sowa <hannes@...essinduktion.org>
To:	Eric Dumazet <eric.dumazet@...il.com>,
	David Miller <davem@...emloft.net>
Cc:	zenczykowski@...il.com, lorenzo@...gle.com,
	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, Nov 19, 2015, at 17:19, Eric Dumazet wrote:
> 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.

I actually don't have an issue with killing from user space that much. I
still recommend (and actually have started to look at it today) to add a
new substate for TCP TIMEWAIT and don't have any issue if we block the
socket for 60 seconds and send RSTs to all incoming data. This way we
can solve the problem Florian indicated as well as this problem. Users
can happily kill TCP connections then.

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