netdev - Re: virtio_net: Set correct gso->hdr

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]

Date:	Fri, 5 Jun 2009 16:20:02 +0930
From:	Rusty Russell <rusty@...tcorp.com.au>
To:	Herbert Xu <herbert@...dor.apana.org.au>
Cc:	"David S. Miller" <davem@...emloft.net>, netdev@...r.kernel.org
Subject: Re: virtio_net: Set correct gso->hdr_len

On Fri, 5 Jun 2009 01:57:09 pm Herbert Xu wrote:
> On Fri, Jun 05, 2009 at 01:51:05PM +0930, Rusty Russell wrote:
> > But are we allowed to make the assumption that skb_headlen() ==
> > skb_transport_header(skb) + sizeof(transport header) ?  Or should we be
> > checking that here?
>
> We don't care.  We just want to preserve whatever the OS gave us.
> If it's bogus, the backend will reject it or fix it up.

Right, understood now.  It really is just a hint as to how much to copy.  It 
wasn't supposed to be that, as virtio_net.h:

	__u16 hdr_len;		/* Ethernet + IP + tcp/udp hdrs */
	__u16 gso_size;		/* Bytes to append to hdr_len per frame */

The host was supposed to be able to de-gso packets together relying on 
hdr_len.  But that's silly: it can't do TSO without knowing about sequence 
numbers at least, and UFO without ip fragmentation offsets.  ie. it might as 
well calc hdr_len itself.

I'm working on a proper spec, I'll be sure to note this.

Thanks,
Rusty.
--
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