netdev - Re: [RFC] addition of a dropped packet notification service

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:	Wed, 25 Feb 2009 09:18:41 -0500
From:	Neil Horman <nhorman@...driver.com>
To:	David Miller <davem@...emloft.net>
Cc:	herbert@...dor.apana.org.au, shemminger@...tta.com,
	netdev@...r.kernel.org, kuznet@....inr.ac.ru, pekkas@...core.fi,
	jmorris@...ei.org, yoshfuji@...ux-ipv6.org
Subject: Re: [RFC] addition of a dropped packet notification service

On Wed, Feb 25, 2009 at 04:01:30AM -0800, David Miller wrote:
> From: Neil Horman <nhorman@...driver.com>
> Date: Wed, 25 Feb 2009 06:54:19 -0500
> 
> > I had actually started down this road for awhile, and liked it for
> > its low maintenence overhead (as you mentioned, less to annotate),
> > but I balked at it after a bit, mostly for its increased ambiguity.
> > By catching the drop where the packet is freed, we lose information
> > about the exact point at which we decided to drop it.  As such,
> > users of said dumped table loose (or potentially lose) the ability
> > to correlate the saved stack pointer with an exact point in the code
> > where a corresponding statistic was incremented, as well as the
> > correlation to a specific point in the code (they just get the
> > calling function program counter rather than file, funciton and line
> > number).
> 
> Userland tools can extract this information from a non-stripped
> kernel image file, given just a kernel PC value.
> 
Sure, they can, but my origional post had this information captured at the drop
point (using __func__, __file__ and __LINE__).  My intent was that no debuginfo
package should be needed for a user to determine the point of the drop, just the
source tree (which can be consolidated to one location for multiple hosts, via
lxer, etc.), rather than installed on each individual machine.

Although as I think about it, theres no reason that a user space utility can't
use a symboled kernel to translate pc values if available, and do a reduced
symbol+offset translation using /proc/kallsyms in its absence.

> And you need the same thing to extract the same information
> if you used tracepoints.
> 
Well, I think the above implementation can be done with or without tracepoints.
The mechanism by which we get the drop information is orthogonal to what we do
with it.

Thanks for the feedback guys.  I'll start modifying my kernel changes to reflect
this striaght away.  If you'd like to see something in the interim, let me know
and I'll send you what I have.  Currently I've got the user space delivery
mechanism working as a Netlink protocol, and with your above suggestions, I
expect to have the drop capture piece recode and working in the next few weeks.

Best
Neil

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