netdev - Re: [net] e1000: Small packets may get corrupted during padding by HW

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: <1347915723.26523.179.camel@edumazet-glaptop>
Date:	Mon, 17 Sep 2012 23:02:03 +0200
From:	Eric Dumazet <eric.dumazet@...il.com>
To:	Alexander Duyck <alexander.h.duyck@...el.com>
Cc:	"Dave, Tushar N" <tushar.n.dave@...el.com>,
	"Fastabend, John R" <john.r.fastabend@...el.com>,
	Michal Miroslaw <mirqus@...il.com>,
	"Kirsher, Jeffrey T" <jeffrey.t.kirsher@...el.com>,
	"davem@...emloft.net" <davem@...emloft.net>,
	"netdev@...r.kernel.org" <netdev@...r.kernel.org>,
	"gospo@...hat.com" <gospo@...hat.com>,
	"sassmann@...hat.com" <sassmann@...hat.com>
Subject: Re: [net] e1000: Small packets may get corrupted during padding by
 HW

On Mon, 2012-09-17 at 13:53 -0700, Alexander Duyck wrote:
> On 09/17/2012 12:58 AM, Eric Dumazet wrote:
> > On Mon, 2012-09-17 at 07:33 +0000, Dave, Tushar N wrote:
> >>> -----Original Message-----
> >>> From: netdev-owner@...r.kernel.org [mailto:netdev-owner@...r.kernel.org]
> >>> On Behalf Of John Fastabend
> >>> Also wouldn't you want an unlikely() in your patch?
> >> No because it is quite normal to have packet < ETH_ZLEN. e.g. ARP packets.
> > ARP packets ? Hardly a performance problem.
> >
> > Or make sure all these packets have enough tailroom, or else you are
> > going to hit the cost of reallocating packets.
> >
> > I would better point TCP pure ACK packets, since their size can be 54
> > bytes.
> >
> > diff --git a/net/ipv4/tcp_output.c b/net/ipv4/tcp_output.c
> > index cfe6ffe..aefc681 100644
> > --- a/net/ipv4/tcp_output.c
> > +++ b/net/ipv4/tcp_output.c
> > @@ -3083,8 +3083,9 @@ void tcp_send_ack(struct sock *sk)
> >  	/* We are not putting this on the write queue, so
> >  	 * tcp_transmit_skb() will set the ownership to this
> >  	 * sock.
> > +	 * Add 64 bytes of tailroom so that some drivers can use skb_pad()
> >  	 */
> > -	buff = alloc_skb(MAX_TCP_HEADER, sk_gfp_atomic(sk, GFP_ATOMIC));
> > +	buff = alloc_skb(MAX_TCP_HEADER + 64, sk_gfp_atomic(sk, GFP_ATOMIC));
> >  	if (buff == NULL) {
> >  		inet_csk_schedule_ack(sk);
> >  		inet_csk(sk)->icsk_ack.ato = TCP_ATO_MIN;
> For most systems that extra padding should already be added since
> alloc_skb will cache line align the buffer anyway.
> 

Please define 'most systems' ?

> A more general fix might be to make it so that alloc_skb cannot allocate
> less than 60 byte buffers on systems with a cache line size smaller than
> 64 bytes.

Nope, because we do a skb_reserve(skb, MAX_TCP_HEADER)

So we might have no bytes available at all after this MAX_TCP_HEADER
area.

Relying on extra padding in alloc_skb() is hacky anyway, as it
depends on external factors (external to TCP stack)



--
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