netdev - Re: [PATCH v2 0/2] Tracepoint for tcp retransmission

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Mon, 6 Feb 2012 10:53:05 -0500
From:	Neil Horman <nhorman@...driver.com>
To:	"Frank Ch. Eigler" <fche@...hat.com>
Cc:	Hagen Paul Pfeifer <hagen@...u.net>,
	"Frank Ch. Eigler" <fche@...stic.org>,
	Satoru Moriya <satoru.moriya@....com>,
	David Miller <davem@...emloft.net>,
	"netdev@...r.kernel.org" <netdev@...r.kernel.org>,
	"tgraf@...radead.org" <tgraf@...radead.org>,
	"stephen.hemminger@...tta.com" <stephen.hemminger@...tta.com>,
	"eric.dumazet@...il.com" <eric.dumazet@...il.com>,
	Seiji Aguchi <seiji.aguchi@....com>, fche@...rceware.org,
	mathieu.desnoyers@...ymtl.ca, rostedt@...dmis.org
Subject: Re: [PATCH v2 0/2] Tracepoint for tcp retransmission

On Mon, Feb 06, 2012 at 10:20:19AM -0500, Frank Ch. Eigler wrote:
> Hi, Neil -
> 
> On Sun, Feb 05, 2012 at 08:32:47PM -0500, Neil Horman wrote:
> 
> > [...]
> > > Hey Neil, I though about this more deeply. In my first iteration I
> > > had the same answer. But IMHO if you think about this more deeply,
> > > I think this is not a scalable approach (implementing in userspace
> > > as systemtap scripts compared to implement them in kernelspace
> > > (tracepoints). Why? Because at a deep TCP level the API (and thus
> > > the context) is not static and the meaning of return values (or
> > > arguments) change over time. No matter _where_ it is implemented
> > > or coded.
> 
> > Yes, this is why I'm suggesting alternatives to the tracepoint.
> 
> I believe Hagen's point was that alternatives to tracepoints would
> have substantially the same difficulty.  At some point in the stack,
> you have to standardize/abstract.  What you hook up *at that point* is
> not too important: tracepoints, or function calls, or expanded perf
> machinery all seem to have the same burden.
> 
Yes, that was his point.  Mine was that, given Satoru's needs, a netfilter hook
provides 90% of what they need (as its been described here).  If you're
unfamiliar with them, netfilter hooks are those standard points in the network
input/output/forwarding paths at which we can watch and maniupulate network
traffic.  They're what iptables/ip6tables/ebtables/etc use to do everything they
do.  I'm suggesting that they use those existing hooks to monitor outgoing
traffic for whatever information they want (in this case retransmitted unacked
tcp sequence numbers).  Or whatever else their interested in.

As for the other 10% (recording failed retransmits, which don't generate
traffic), we have existing tracepoints that can be used.

> 
> > [...] If something is needed in the short term for Satoru, I still
> > think a privately maintained module that registers a netfilter hook
> > to watch outgoing packets for retransmits offers a good solution.
> 
> Does this mean that this netfilter hook mechanism is sufficient to
> adapt to the current/future diversity of behaviors?  Why not make
> *that* into a tracepoint then, so perf/stap scripts could get at it in
> userspace?
> 
I suppose you could.  In fact there is a queue target that lets you shuttle
frames from netfilter hook points up to userspace already, so you could do that.
I'm suggesting a kernel module because then you wouldn't have the performance
overhead of moving all those frames to user space.
Neil

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