netdev - Re: [PATCH net-next 05/15] ipv6/gso: remove temporary HBH/jumbo 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]

Date:   Thu, 3 Feb 2022 13:41:56 -0800
From:   Eric Dumazet <edumazet@...gle.com>
To:     Alexander H Duyck <alexander.duyck@...il.com>
Cc:     Eric Dumazet <eric.dumazet@...il.com>,
        "David S . Miller" <davem@...emloft.net>,
        Jakub Kicinski <kuba@...nel.org>,
        netdev <netdev@...r.kernel.org>, Coco Li <lixiaoyan@...gle.com>
Subject: Re: [PATCH net-next 05/15] ipv6/gso: remove temporary HBH/jumbo header

On Thu, Feb 3, 2022 at 1:08 PM Alexander H Duyck
<alexander.duyck@...il.com> wrote:
>
> On Thu, 2022-02-03 at 11:59 -0800, Eric Dumazet wrote:
> > On Thu, Feb 3, 2022 at 11:45 AM Alexander Duyck
> > <alexander.duyck@...il.com> wrote:
> >
> > > It is the fact that you are adding IPv6 specific code to the
> > > net/core/skbuff.c block here. Logically speaking if you are adding the
> > > header in ipv6_gro_receive then it really seems li:ke the logic to
> > > remove the header really belongs in ipv6_gso_segment. I suppose this
> > > is an attempt to optimize it though, since normally updates to the
> > > header are done after segmentation instead of before.
> >
> > Right, doing this at the top level means we do the thing once only,
> > instead of 45 times if the skb has 45 segments.
>
> I'm just wondering if there is a way for us to do it in
> ipv6_gso_segment directly instead though. With this we essentially end
> up having to free the skb if the segmentation fails anyway since it
> won't be able to go out on the wire.
>

Having a HBH jumbo header in place while the current frame is MTU size
(typically MTU < 9000) would
violate the specs. A HBH jumbo header presence implies packet length > 64K.



> If we assume the stack will successfully segment the frame then it
> might make sense to just take care of the hop-by-hop header before we
> start processing the L4 protocol.