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: <CALMXkpbNeRCrOnQFWAWR8BzX4yRgDveDMPZgS6NupjXrHFX1pg@mail.gmail.com>
Date:   Fri, 5 Jun 2020 07:57:46 -0700
From:   Christoph Paasch <christoph.paasch@...il.com>
To:     Eric Dumazet <eric.dumazet@...il.com>
Cc:     Julian Anastasov <ja@....bg>, Wayne Badger <badger@...oo-inc.com>,
        "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
        Leif Hedstrom <lhedstrom@...le.com>
Subject: Re: TCP_DEFER_ACCEPT wakes up without data

On Thu, Jun 4, 2020 at 6:28 PM Eric Dumazet <eric.dumazet@...il.com> wrote:
>
>
>
> On 6/4/20 4:18 PM, Christoph Paasch wrote:
> > +Eric & Leif
> >
> > Hello,
> >
> >
> > (digging out an old thread ... ;-) )
> >
>
> Is there a tldr; ?

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