netdev - Re: [PATCH] IPv6: Set SIT tunnel hard_header

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: <dc8f00ff-d484-f5cf-97a3-9f6d8984160e@gmail.com>
Date:   Wed, 4 Nov 2020 20:30:20 +0100
From:   Oliver Herms <oliver.peter.herms@...il.com>
To:     Willem de Bruijn <willemdebruijn.kernel@...il.com>
Cc:     Network Development <netdev@...r.kernel.org>,
        David Miller <davem@...emloft.net>,
        Alexey Kuznetsov <kuznet@....inr.ac.ru>,
        Hideaki YOSHIFUJI <yoshfuji@...ux-ipv6.org>,
        Jakub Kicinski <kuba@...nel.org>
Subject: Re: [PATCH] IPv6: Set SIT tunnel hard_header_len to zero

On 03.11.20 19:42, Willem de Bruijn wrote:
> Thanks. Yes, this is long overdue.
> 
> The hard_header_len issue was also recently discussed in the context
> of GRE in commit fdafed459998 ("ip_gre: set dev->hard_header_len and
> dev->needed_headroom properly").
> 
> Question is whether we should reserve room in needed_headroom instead.
> AFAIK this existing update logic in ip6_tnl_xmit is sufficient
> 
> "
>         /* Calculate max headroom for all the headers and adjust
>          * needed_headroom if necessary.
>          */
>         max_headroom = LL_RESERVED_SPACE(dst->dev) + sizeof(struct ipv6hdr)
>                         + dst->header_len + t->hlen;
>         if (max_headroom > dev->needed_headroom)
>                 dev->needed_headroom = max_headroom;
> "I think that's enough. At least it definitely works in my test and prod environment.
Would be good to get another opinion on this though.

>> Fixes: c54419321455 ("GRE: Refactor GRE tunneling code.")
> 
> How did you arrive at this SHA1?
I think the legacy usage of hard_header_len in ipv6/sit.c was overseen in c54419321455.
Please correct me if I'm wrong.