linux-kernel - Re: [PATCH net-next] tcp: Fix tcp_syn_flood_action() if CONFIG

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]

Date:   Thu, 17 Nov 2022 08:39:43 +1100
From:   Jamie Bainbridge <jamie.bainbridge@...il.com>
To:     Jakub Kicinski <kuba@...nel.org>
Cc:     Geert Uytterhoeven <geert+renesas@...der.be>,
        Eric Dumazet <edumazet@...gle.com>,
        "David S . Miller" <davem@...emloft.net>,
        Hideaki YOSHIFUJI <yoshfuji@...ux-ipv6.org>,
        David Ahern <dsahern@...nel.org>,
        Paolo Abeni <pabeni@...hat.com>,
        Chris Down <chris@...isdown.name>,
        Stephen Hemminger <stephen@...workplumber.org>,
        netdev@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH net-next] tcp: Fix tcp_syn_flood_action() if CONFIG_IPV6=n

On Thu, 17 Nov 2022 at 07:31, Jakub Kicinski <kuba@...nel.org> wrote:
>
> On Tue, 15 Nov 2022 11:12:16 +0100 Geert Uytterhoeven wrote:
> > If CONFIG_IPV6=n:
> >
> >     net/ipv4/tcp_input.c: In function ‘tcp_syn_flood_action’:
> >     include/net/sock.h:387:37: error: ‘const struct sock_common’ has no member named ‘skc_v6_rcv_saddr’; did you mean ‘skc_rcv_saddr’?
> >       387 | #define sk_v6_rcv_saddr __sk_common.skc_v6_rcv_saddr
> >         |                                     ^~~~~~~~~~~~~~~~
> >     include/linux/printk.h:429:19: note: in definition of macro ‘printk_index_wrap’
> >       429 |   _p_func(_fmt, ##__VA_ARGS__);    \
> >         |                   ^~~~~~~~~~~
> >     include/linux/printk.h:530:2: note: in expansion of macro ‘printk’
> >       530 |  printk(KERN_INFO pr_fmt(fmt), ##__VA_ARGS__)
> >         |  ^~~~~~
> >     include/linux/net.h:272:3: note: in expansion of macro ‘pr_info’
> >       272 |   function(__VA_ARGS__);    \
> >         |   ^~~~~~~~
> >     include/linux/net.h:288:2: note: in expansion of macro ‘net_ratelimited_function’
> >       288 |  net_ratelimited_function(pr_info, fmt, ##__VA_ARGS__)
> >         |  ^~~~~~~~~~~~~~~~~~~~~~~~
> >     include/linux/net.h:288:43: note: in expansion of macro ‘sk_v6_rcv_saddr’
> >       288 |  net_ratelimited_function(pr_info, fmt, ##__VA_ARGS__)
> >         |                                           ^~~~~~~~~~~
> >     net/ipv4/tcp_input.c:6847:4: note: in expansion of macro ‘net_info_ratelimited’
> >      6847 |    net_info_ratelimited("%s: Possible SYN flooding on port [%pI6c]:%u. %s.\n",
> >         |    ^~~~~~~~~~~~~~~~~~~~
> >
> > Fix this by using "#if" instead of "if", like is done for all other
> > checks for CONFIG_IPV6.
> >
> > Fixes: d9282e48c6088105 ("tcp: Add listening address to SYN flood message")
> > Signed-off-by: Geert Uytterhoeven <geert+renesas@...der.be>
>
> Sorry for the late reaction, this now conflicts with bf36267e3ad3df8
>
> I was gonna hand edit but perhaps we can do better with the ifdef
> formation.
>
> Instead of
>
> #ifdef v6
>         if (v6) {
>                 expensive_call6();
>         } else    //  d k
> #endif            //  o i
>         {         //  o e
>                 expensive_call4();
>         }

I actually started off using this way in my v1. I did that
intentionally because that pattern already exists in other places,
discussed at:

 https://lore.kernel.org/netdev/CAAvyFNg1F8ixrgy0YeL-TT5xLmk8N7dD=ZMLQ6VxsjHb_PU9bg@mail.gmail.com/

or just see:

 grep -C1 -ERHn "IS_ENABLED\(CONFIG_IPV6\)" net | grep -C1 "family == AF_INET6"

Geert's patch adheres to existing style, which seems the better option?

> Can we go with:
>
> #ifdef v6
>         if (v6)
>                 expensive_call6();
>         else
> #endif
>                 expensive_call4();

This is a nested if, so it really should have braces to prevent
dangling else, both now and in the future.

> or
>
>         if (v4) {
>                 expensive_call4();
> #ifdef v6
>         } else {
>                 expensive_call6();
> #endif
>         }
> or
>
>         if (v6) {
> #ifdef v6
>                 expensive_call6();
> #endif
>         } else {
>                 expensive_call6();
>         }

These should work, but I expect they cause a comparison which can't be
optimised out at compile time. This is probably why the first style
exists.

In this SYN flood codepath optimisation doesn't matter because we're
doing ratelimited logging anyway. But if we're breaking with existing
style, then wouldn't the others also have to change to this style? I
haven't reviewed all the other usage to tell if they're in an oft-used
fastpath where such a thing might matter.

It seems Geert's patch style is the best way.

Jamie