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 PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Mon, 4 Jun 2007 14:09:27 +0200 From: Christoph Raisch <RAISCH@...ibm.com> To: Stephen Hemminger <shemminger@...ux-foundation.org> Cc: Jan-Bernd Themann <themann@...ibm.com>, Jeff Garzik <jeff@...zik.org>, "linux-kernel" <linux-kernel@...r.kernel.org>, "linux-ppc" <linuxppc-dev@...abs.org>, Marcus Eder <meder@...ibm.com>, netdev <netdev@...r.kernel.org>, Stefan Roscher <ossrosch@...ux.vnet.ibm.com>, ossthema@...ux.vnet.ibm.com, Thomas Q Klein <tklein@...ibm.com>, tklein@...ux.ibm.com Subject: Re: [PATCH 2/2] ehea: Receive SKB Aggregation 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 - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@...r.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists