netdev - Re: [PATCH 2/4] xen-netfront: drop skb when skb->len

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: <1365518703.2623.6.camel@bwh-desktop.uk.solarflarecom.com>
Date:	Tue, 9 Apr 2013 15:45:03 +0100
From:	Ben Hutchings <bhutchings@...arflare.com>
To:	Ian Campbell <Ian.Campbell@...rix.com>
CC:	Wei Liu <wei.liu2@...rix.com>,
	"netdev@...r.kernel.org" <netdev@...r.kernel.org>,
	"xen-devel@...ts.xen.org" <xen-devel@...ts.xen.org>,
	"konrad.wilk@...cle.com" <konrad.wilk@...cle.com>,
	"annie.li@...cle.com" <annie.li@...cle.com>
Subject: Re: [PATCH 2/4] xen-netfront: drop skb when skb->len > 65535

On Tue, 2013-04-09 at 15:30 +0100, Ian Campbell wrote:
> On Tue, 2013-03-19 at 21:28 +0000, Ben Hutchings wrote:
> > On Tue, 2013-03-19 at 21:24 +0000, Ben Hutchings wrote:
> > > On Mon, 2013-03-18 at 15:07 +0000, Ian Campbell wrote:
> > > > On Mon, 2013-03-18 at 15:04 +0000, Wei Liu wrote:
> > > > > On Mon, 2013-03-18 at 14:54 +0000, Ian Campbell wrote:
> > > > > > On Mon, 2013-03-18 at 14:40 +0000, Wei Liu wrote:
> > > > > > > On Mon, 2013-03-18 at 11:42 +0000, Ian Campbell wrote:
> > > > > > > > On Mon, 2013-03-18 at 10:35 +0000, Wei Liu wrote:
> > > > > > > > > The `size' field of Xen network wire format is uint16_t, anything bigger than
> > > > > > > > > 65535 will cause overflow.
> > > > > > > > > 
> > > > > > > > > Signed-off-by: Wei Liu <wei.liu2@...rix.com>
> > > > > > > > > ---
> > > > > > > > >  drivers/net/xen-netfront.c |   12 ++++++++++++
> > > > > > > > >  1 file changed, 12 insertions(+)
> > > > > > > > > 
> > > > > > > > > diff --git a/drivers/net/xen-netfront.c b/drivers/net/xen-netfront.c
> > > > > > > > > index 5527663..8c3d065 100644
> > > > > > > > > --- a/drivers/net/xen-netfront.c
> > > > > > > > > +++ b/drivers/net/xen-netfront.c
> > > > > > > > > @@ -547,6 +547,18 @@ static int xennet_start_xmit(struct sk_buff *skb, struct net_device *dev)
> > > > > > > > >  	unsigned int len = skb_headlen(skb);
> > > > > > > > >  	unsigned long flags;
> > > > > > > > >  
> > > > > > > > > +	/*
> > > > > > > > > +	 * wire format of xen_netif_tx_request only supports skb->len
> > > > > > > > > +	 * < 64K, because size field in xen_netif_tx_request is
> > > > > > > > > +	 * uint16_t.
> > > > > > > > 
> > > > > > > > Is there some field we can set e.g. in struct ethernet_device which
> > > > > > > > would stop this from happening?
> > > > > > > > 
> > > > > > > 
> > > > > > > struct ethernet_device? I could not find it.
> > > > > > > 
> > > > > > > And for struct net_device,
> > > > > > 
> > > > > > I meant struct net_device.
> > > > > > 
> > > > > > >  there is no field for this AFAICT.
> > > > > > 
> > > > > > Interesting. Are hardware devices expected to cope with arbitrary sized
> > > > > > GSO skbs then I wonder.
> > > > > > 
> > > > > 
> > > > > No idea. But there is a macro called GSO_MAX_SIZE (65536) in struct
> > > > > net_device. :-)
> > > > 
> > > > But aren't we seeing skb's bigger than that?
> > > > 
> > > > Maybe this is just a historical bug in some older guests?
> > > 
> > > GSO_MAX_SIZE is the maximum payload length, not the maximum total length
> > > of an skb.
> > 
> > ...and it's actually just the default value assigned to
> > dev->gso_max_size.  You'll want to change it to your actual maximum
> > (65535 - maximum length of headers) before registering your net devices.
> 
> Thanks. 
> 
> "maximum length of headers" might be a bit tricky to determine
> generically :-(.

Well you don't need to be generic, you need to know the maximum length
of headers that might appear in a TSO skb.

Ethernet + VLAN tag + IPv6 + TCP + timestamp option = 90 bytes, but I'm
not sure whether there can be other IP or TCP options in a TSO skb.  I'd
really like to get the TSO requirements clearly documented somewhere.

Ben.

-- 
Ben Hutchings, Staff Engineer, Solarflare
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.

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