netdev - Re: 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: <200808121227.43732.rusty@rustcorp.com.au>
Date:	Tue, 12 Aug 2008 12:27:43 +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: Re: csum offload and af_packet

On Tuesday 12 August 2008 10:32:44 Herbert Xu wrote:
> On Mon, Aug 11, 2008 at 11:50:25PM +1000, Rusty Russell wrote:
> > 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.
>
> I disagree.  If you're using AF_PACKET you're asking to see the
> bare details.  If you want to see the censored version you can
> always go through the IP stack.

Then should we insist the user set PACKET_AUXDATA?  Even then, the format of 
that cmsg will have to be enhanced as we change kernel internals.  Which is 
probably why you *don't* get to see the bare details: you get a flag 
saying "oh, I know the checksum is bad".  Without the csum_start/csum_offset 
fields you can't even calculate what it will be.

The dhcp client thing is a symptom which can be fixed, but are we doing the 
right thing?  (Tho for lguest this is a new problem with the current kernel, 
so fixing it now means it really wouldn't be a problem).

> > 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?
>
> It's not about disabling it, it's about enabling it dynamically
> once guest user-space is sure that *it* can handle this.

Oh, I see.  I'd have to think harder; I'm not sure if we have all the pieces 
at the moment for virtio or would need a boutique mechanism for this (usually 
the host doesn't change the features it offers, even if device resets).  May 
be easier to suppress csum offload for dhcp packets in the host...

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