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  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:	Thu, 19 Nov 2015 16:04:18 -0800
From:	Tom Herbert <>
To:	Eric Dumazet <>
Cc:	David Miller <>,
	zenczykowski <>,
	Lorenzo Colitti <>,
	Hannes Frederic Sowa <>,
	Stephen Hemminger <>,
	Linux Kernel Network Developers <>,
	Eric Dumazet <>, Erik Kline <>,
	Dmitry Torokhov <>
Subject: Re: Add a SOCK_DESTROY operation to close sockets from userspace

On Thu, Nov 19, 2015 at 2:33 PM, Eric Dumazet <> wrote:
> On Thu, 2015-11-19 at 14:14 -0800, Tom Herbert wrote:
>> On Thu, Nov 19, 2015 at 2:07 PM, Eric Dumazet <> wrote:
>> > On Thu, 2015-11-19 at 13:53 -0800, Tom Herbert wrote:
>> >
>> >> That covers the case where the local address is removed, but the not
>> >> the case where the network manager is informed of an error in the path
>> >> and wants to signal the application. My understanding was that
>> >> SIOCKILLADDR would work for the first case, but this patch was need to
>> >> cover the second case.
>> >>
>> >> btw, instead of closing the TCP socket can we just report an error and
>> >> wake up the application without affecting the connection? That is this
>> >> just becomes an error on the socket. The response by the application
>> >> will be the same in any case, porbablly just close the socket and try
>> >> to reestablish the connection.
>> >
>> > I thought this was the patch intent ?
>> >
>> > Application gets a EPOLLIN|EPOLLOUT|POLLERR notification (if it is
>> > willing to receive it, or blocked in a socket syscall) and closes the
>> > socket.
>> >
>> >          sk->sk_err = ETIMEDOUT;
>> >          sk->sk_error_report(sk);
>> >          tcp_done(sk);
>> >
>> The tcp_done is not needed here. This is the difference between the
>> application having the connection closed underneath them, versus the
>> application performing a close to terminate the connection. The latter
>> behavior preserves the semantics that only the stack or the
>> application owning the socket can initiate a state change on the
>> connection.
> The code behaves like we received a formal RST :
But we didn't get a RST, closing the connection is not being done
under the auspices of the protocol. The most comparable event to be a
timeout on the socket read operation.

> Please do not even bother trying to send additional data, it is not
> worth wasting precious resource.
It is reasonable to think of this mechanism as way to indicate loss of
reachability. But if this is being viewed as a way to do resource
management that is a little worrisome. What is to stop someone from
using this mechanism from implementing to implement a security layer,
or imposing a global time limit to how long someone can be connected,
or to start killing connections based on some arbitrary policy when
under memory pressure. I am not necessarily saying this stuff is
necessarily bad or an abuse of the mechanism, but the flexibility and
power of the mechanism opens the door for these use cases.

To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to
More majordomo info at

Powered by blists - more mailing lists