On Fri, Dec 05, 2003 at 12:28:19PM -0800, David S. Miller wrote: > Some auditing is definitely necessary wrt. TSO and netfilter. In particular > I am incredibly confident that we have issues in cases like when the FTP > netfilter modules mangle the data. I didn't have a look into how TSO is implemented until today. From my naive point of view, I cannot think of any issues. From a netfilter point of view, a TSO-enabled skb just looks like a single large packet, right? I mean, the TSO-enabled skb still contains a fully valid IP and TCP packet. If we do any changes to the IP header or tcp header bits, or even to the payload of the packet, this happens before the TSO-enabled driver and the network board start creating multiple tcp/ip datagrams from this skb (by using the information present in the netfilter-modified ip/tcp headers). The only interesting case is in ip_output.c:ip_queue_xmit(), where tso_size and tso_segs are calculated, before NF_IP_LOCAL_OUT is run. But changing the content or the size of the tcp payload should not affect those calculations. A real problem would be resizing the TCP header (where th.doff is affected). But I cannot think of any case where any of the current netfilter/iptables/conntrack/nat code does that. Even in the past, when we used to remove SACKPERM from the tcp header, we just NOP'ed it out instead of resizing the header. > Another area for inspection are the cases where TCP header bits are > changed and thus the checksum needs to be adjusted. Why is this a problem? The netfilter code has to adjust the checksum anyway... or is the checksum calculation for TSO-enabled skb's different? Please enlighten me if I have missed something. -- - Harald Welte http://www.netfilter.org/ ============================================================================ "Fragmentation is like classful addressing -- an interesting early architectural error that shows how much experimentation was going on while IP was being designed." -- Paul Vixie