netdev - Re: Why not use all the syn queues? in the function "tcp_conn

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]

Message-ID: <vN3mecCgCus4YcjtQ_kmAF54GhPE5BuQBEmDmPauw6J-FAWXZfzrXiw15lD6p2TmQtEH_ZORkfbA7BYgu7XeBIAXVzto628SNysPZz2Ia9s=@protonmail.com>
Date:   Wed, 05 Sep 2018 00:20:25 +0000
From:   Ttttabcd <ttttabcd@...tonmail.com>
To:     Neal Cardwell <ncardwell@...gle.com>
Cc:     Netdev <netdev@...r.kernel.org>
Subject: Re: Why not use all the syn queues? in the function "tcp_conn_request", I have some questions.




Sent with ProtonMail Secure Email.

‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On 4 September 2018 9:06 PM, Neal Cardwell <ncardwell@...gle.com> wrote:

> On Tue, Sep 4, 2018 at 1:48 AM Ttttabcd ttttabcd@...tonmail.com wrote:
>
> > Hello everyone,recently I am looking at the source code for handling TCP three-way handshake(Linux Kernel version 4.18.5).
> > I found some strange places in the source code for handling syn messages.
> > in the function "tcp_conn_request"
> > This code will be executed when we don't enable the syn cookies.
> >
> >                 if (!net->ipv4.sysctl_tcp_syncookies &&
> >                     (net->ipv4.sysctl_max_syn_backlog - inet_csk_reqsk_queue_len(sk) <
> >                      (net->ipv4.sysctl_max_syn_backlog >> 2)) &&
> >                     !tcp_peer_is_proven(req, dst)) {
> >                         /* Without syncookies last quarter of
> >                          * backlog is filled with destinations,
> >                          * proven to be alive.
> >                          * It means that we continue to communicate
> >                          * to destinations, already remembered
> >                          * to the moment of synflood.
> >                          */
> >                         pr_drop_req(req, ntohs(tcp_hdr(skb)->source),
> >                                     rsk_ops->family);
> >                         goto drop_and_release;
> >                 }
> >
> >
> > But why don't we use all the syn queues?
>
> If tcp_peer_is_proven() returns true then we do allow ourselves to use
> the whole queue.
>
> > Why do we need to leave the size of (net->ipv4.sysctl_max_syn_backlog >> 2) in the queue?
> > Even if the system is attacked by a syn flood, there is no need to leave a part. Why do we need to leave a part?
>
> The comment describes the rationale. If syncookies are disabled, then
> the last quarter of the backlog is reserved for filling with
> destinations that were proven to be alive, according to
> tcp_peer_is_proven() (which uses RTTs measured in previous
> connections). The idea is that if there is a SYN flood, we do not want
> to use all of our queue budget on attack traffic but instead want to
> reserve some queue space for SYNs from real remote machines that we
> have actually contacted in the past.
>
> > The value of sysctl_max_syn_backlog is the maximum length of the queue only if syn cookies are enabled.
>
> Even if syncookies are disabled, sysctl_max_syn_backlog is the maximum
> length of the queue.
>
> > This is the first strange place, here is another strange place
> >
> >         __u32 isn = TCP_SKB_CB(skb)->tcp_tw_isn;
> >
> >         if ((net->ipv4.sysctl_tcp_syncookies == 2 ||
> >              inet_csk_reqsk_queue_is_full(sk)) && !isn) {
> >
> >         if (!want_cookie && !isn) {
> >
> >
> > The value of "isn" comes from TCP_SKB_CB(skb)->tcp_tw_isn, then it is judged twice whether its value is indeed 0.
> > But "tcp_tw_isn" is initialized in the function "tcp_v4_fill_cb"
> >
> >         TCP_SKB_CB(skb)->tcp_tw_isn = 0;
> >
> >
> > So it has always been 0, I used printk to test, and the result is always 0.
>
> That field is also set in tcp_timewait_state_process():
>
> TCP_SKB_CB(skb)->tcp_tw_isn = isn;
>
> So there can be cases where it is not 0.
>
> Hope that helps,
> neal

Thank you very much, I understand