netdev - Re: TCP_DEFER_ACCEPT wakes up without data

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: <D38E6A8A-5B3F-4C26-9A2F-D6FEF2D8763B@apple.com>
Date:   Sun, 07 Jun 2020 09:05:03 -0600
From:   Leif Hedstrom <lhedstrom@...le.com>
To:     Florian Westphal <fw@...len.de>
Cc:     Eric Dumazet <eric.dumazet@...il.com>,
        Christoph Paasch <christoph.paasch@...il.com>,
        Julian Anastasov <ja@....bg>,
        Wayne Badger <badger@...oo-inc.com>,
        "netdev@...r.kernel.org" <netdev@...r.kernel.org>
Subject: Re: TCP_DEFER_ACCEPT wakes up without data



> On Jun 7, 2020, at 04:01, Florian Westphal <fw@...len.de> wrote:
> 
> Eric Dumazet <eric.dumazet@...il.com> wrote:
>>> Sure! TCP_DEFER_ACCEPT delays the creation of the socket until data
>>> has been sent by the client *or* the specified time has expired upon
>>> which a last SYN/ACK is sent and if the client replies with an ACK the
>>> socket will be created and presented to the accept()-call. In the
>>> latter case it means that the app gets a socket that does not have any
>>> data to be read - which goes against the intention of TCP_DEFER_ACCEPT
>>> (man-page says: "Allow a listener to be awakened only when data
>>> arrives on the socket.").
>>> 
>>> In the original thread the proposal was to kill the connection with a
>>> TCP-RST when the specified timeout expired (after the final SYN/ACK).
>>> 
>>> Thus, my question in my first email whether there is a specific reason
>>> to not do this.
>>> 
>>> API-breakage does not seem to me to be a concern here. Apps that are
>>> setting DEFER_ACCEPT probably would not expect to get a socket that
>>> does not have data to read.
>> 
>> Thanks for the summary ;)
>> 
>> I disagree.
>> 
>> A server might have two modes :
>> 
>> 1) A fast path, expecting data from user in a small amount of time, from peers not too far away.
>> 
>> 2) A slow path, for clients far away. Server can implement strategies to control number of sockets
>> that have been accepted() but not yet active (no data yet received).
> 
> So we can't change DEFER_ACCEPT behaviour.
> Any objections to adding TCP_DEFER_ACCEPT2 with the behaviour outlined
> by Christoph?


I think that would be useful, although ideally a better, more descriptive name ?

Cheers,

— Leif