netdev - Re: [PATCH 1/2] [IPV4] UDP: Always checksum even if without socket filter

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:	Tue, 20 Nov 2007 00:29:45 -0500
From:	Bill Fink <billfink@...dspring.com>
To:	David Miller <davem@...emloft.net>
Cc:	andi@...stfloor.org, wangchen@...fujitsu.com,
	herbert@...dor.apana.org.au, netdev@...r.kernel.org
Subject: Re: [PATCH 1/2] [IPV4] UDP: Always checksum even if without socket
 filter

On Mon, 19 Nov 2007, David Miller wrote:

> From: Andi Kleen <andi@...stfloor.org>
> Date: Mon, 19 Nov 2007 16:29:33 +0100
> 
> > > > > 
> > > > > All of our options suck, we just have to choose the least sucking one
> > > > > and right now to me that's decrementing the counter as much as I
> > > > > empathize with the SNMP application overflow detection issue.
> > > > 
> > > > If the SNMP monitor detects an false overflow the error it reports 
> > > > will be much worse than a single missing packet. So you would replace 
> > > > one error with a worse error.
> > > 
> > > This can be fixed, the above cannot.
> > 
> > I don't see how, short of breaking the interface
> > (e.g. reporting 64bit or separate overflow counts)
> 
> As someone who just spent an entire weekend working on
> cpu performance counter code, I know it's possible.
> 
> When you overflow, the new value is "a lot" less than
> the last sampled one.  When the value backtracks like
> we're discussing it could here, it only decrease
> a very little bit.

While I agree with your analysis that it could be worked around,
who knows how all the various SNMP monitoring applications out there
would interpret such an unusual event.  I liked Stephen's suggestion
of a deferred decrement that would insure the counter didn't ever
run backwards.  But the best approach seems to be just not to count
it in the first place until tha application has actually received
the packet, since as Herbert pointed out, that's what the RFC
actually specifies for the meaning of the udpInDatagrams counter.

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