netdev - csum offload and af

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: <200808112350.25514.rusty@rustcorp.com.au>
Date:	Mon, 11 Aug 2008 23:50:25 +1000
From:	Rusty Russell <rusty@...tcorp.com.au>
To:	Herbert Xu <herbert@...dor.apana.org.au>
Cc:	anthony@...emonkey.ws, netdev@...r.kernel.org, davem@...emloft.net
Subject: csum offload and af_packet

On Monday 11 August 2008 19:51:39 Herbert Xu wrote:
> Rusty Russell <rusty@...tcorp.com.au> wrote:
> > add an "else if (skb->ip_summed == CHECKSUM_PARTIAL)" case...
>
> If you're going to hack the guest kernel, then you might as well
> fix the guest DHCP client.  However, we should default checksum
> offload to off until we know that the client is capable of handling
> it (to handle guests that haven't been fixed).

I think this is deeper than that.  This case is actually unusual, in that the 
packet really does arrive with a partial csum.  But usually, we're exposing 
an internal detail of our stack at this point.  Seems like we shouldn't if we 
know the user can't deal with it.  dhcpd just makes this case less academic.

> One easy way of doing this is to hook up the rx checksum offload
> option in the guest with the tx offload option in the host.  In
> other words, when rx offload is enabled in the guest we enable
> tx offload in the host, and disable it vice versa.

We can trivially disable it in the guest or host; that's not the problem.  We 
can even disable csum offload just for UDP in the host.  But should we 
really?

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