[PATCH 2/2] ehea: Receive SKB Aggregation
Christoph Raisch
RAISCH at de.ibm.com
Mon Jun 4 22:09:27 EST 2007
Stephen Hemminger wrote on 31.05.2007 18:37:03:
>
> >
> >
> > +static int try_get_ip_tcp_hdr(struct ehea_cqe *cqe, struct sk_buff
*skb,
> > + struct iphdr **iph, struct tcphdr **tcph)
> > +{
> > + int ip_len;
> > +
> > + /* non tcp/udp packets */
> > + if (!cqe->header_length)
> > + return -1;
> > +
> > + /* non tcp packet */
> > + *iph = (struct iphdr *)(skb->data);
>
> Why the indirection, copying of headers..
This interacts with the header split function in the hardware.
>
> > + if ((*iph)->protocol != IPPROTO_TCP)
> > + return -1;
> > +
> > + ip_len = (u8)((*iph)->ihl);
> > + ip_len <<= 2;
> > + *tcph = (struct tcphdr *)(((u64)*iph) + ip_len);
> > +
> > + return 0;
> > +}
> > +
> >
>
> This code seems to be duplicating a lot (but not all) of the TCP/IP
> input path validation checks. This is a security problem if nothing
else...
>
We should only do aggregation in the driver if this really is a TCP header,
otherwise things will get worse.
You're right, we should at least check that tcph is within the received
frame.
> Also, how do you prevent DoS attacks from hostile TCP senders that send
> huge number of back to back frames?
Actually a huge number of back to back frames is what we would want to
receive
at 10 gbit ;-)
How is it possible to figure out if this is what you want or just DoS?
It doesn't change anything compared to a non LRO driver, we process a
certain
maximum amount of frames before waiting for the next interrupt,
the packet filters/DoS should still see all traffic (which is above the
driver).
Any suggestions how to handle this better/different?
>
> --
> Stephen Hemminger
Gruss / Regards
Christoph Raisch
More information about the Linuxppc-dev
mailing list