netdev - Re: TCP/IPv4 sending using MSG_ZEROCOPY and closing the socket

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Mon, 28 Jan 2019 11:54:36 -0500
From:   Willem de Bruijn <willemdebruijn.kernel@...il.com>
To:     mathias_koehrer@...or.de
Cc:     Network Development <netdev@...r.kernel.org>,
        Willem de Bruijn <willemb@...gle.com>
Subject: Re: TCP/IPv4 sending using MSG_ZEROCOPY and closing the socket

On Mon, Jan 28, 2019 at 2:57 AM <mathias_koehrer@...or.de> wrote:
>
> Hi all,
>
> I have one question on the behavior of TCP/IPv4 sending using the MSG_ZEROCOPY flag,
> the kernel version is 4.19.18.
>
> What happens if I close the sending socket immediately after performing a socket
> send() or sendmsg() call (called with the MSG_ZEROCOPY flag)?
> I.e. in this situation not all messages have been sent yet, however - as the
> socket is closed - it is no longer possible to retrieve the completion
> notification via the error channel.
>
> Is it fine for the user space program to free all outstanding messages after the
> socket close() has returned?
> Or is there anything else that has to be considered?

If closing the socket while user memory is still in transmission, it
will not be possible to safely reuse the memory, as the process has no
way of discovering when the kernel has finished transmission.

Depending on type of memory, there may be workarounds to avoid
unbound virtual memory growth, such as unmapping the virtual
address range in the case of mmap()ed data.

But in general, the right approach is to wait for all completions
before closing a socket.

If this takes a long time, say due to the TCP stack hold on to data for
retransmission in the case a peer does not properly close its side,
disconnect (connect() AF_UNSPEC) can be used to purge the
queues and trigger notifications. Again, this is a last resort and
usually not needed.