netdev - Re: [PATCH net-next 2/4] net: add support for segmenting TCP fraglist GSO packets

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: <ab75baa2c972859df01a29494fb17ad4b0cc0bab.camel@redhat.com>
Date: Fri, 26 Apr 2024 10:00:22 +0200
From: Paolo Abeni <pabeni@...hat.com>
To: Felix Fietkau <nbd@....name>, Willem de Bruijn
 <willemdebruijn.kernel@...il.com>, netdev@...r.kernel.org, Eric Dumazet
 <edumazet@...gle.com>, "David S. Miller" <davem@...emloft.net>, David Ahern
 <dsahern@...nel.org>, Jakub Kicinski <kuba@...nel.org>
Cc: linux-kernel@...r.kernel.org
Subject: Re: [PATCH net-next 2/4] net: add support for segmenting TCP
 fraglist GSO packets

On Thu, 2024-04-25 at 09:51 +0200, Felix Fietkau wrote:
> On 25.04.24 05:03, Willem de Bruijn wrote:
> > Felix Fietkau wrote:
> > > Preparation for adding TCP fraglist GRO support. It expects packets to be
> > > combined in a similar way as UDP fraglist GSO packets.
> > > One difference is the fact that this code assumes that the TCP flags of
> > > all packets have the same value. This allows simple handling of flags
> > > mutations.
> > 
> > Can you clarify this some more? We expect potentially different flags
> > on first and last packet in a TSO train. With fraglist, the segments
> > keep their original flags, as the headers are only pulled. When do
> > segment flags need to be replaced with those of the first segment?
> 
> Maybe I just misunderstood a comment that Paolo made earlier regarding 
> TCP header mutations. Will review this again and compare with regular TSO.

I likely was not clear, I'm sorry.

Let me try to rephrase. After the GRO stage, and before segmentation,
the stack could change other fields inside the TCP header (beyond
src/dst port). e.g. nftables can clear the ECN bit, or strip all the
TCP options.

The frag_list segmentation should catch such changes and update the
individual segments csum accordingly.

Note that even IPv6 could snat/dnat a packet!

The GRO stage allows aggregating with different flags. Later on, at
segmentation stage, all the individual packets except the last one will
retain the same flags of the first segment, except for the PUSH and FIN
bit, that will be cleared. The last segment will have such bit value
preserved.

Cheers,

Paolo