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: Windows password security audit tool. GUI, reports in PDF.

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

Date:	Sun, 5 Feb 2012 21:04:29 +0100
From:	Hagen Paul Pfeifer <hagen@...u.net>
To:	Neil Horman <nhorman@...driver.com>
Cc:	"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

* Neil Horman | 2012-02-05 14:17:08 [-0500]:

>Generally the fact that probe points may shift underneath a script between
>kernels.  While its often ok, theres no guaranteed fixed set of probe points.
>While it often works, theres always the possibility that functional changes,
>even if they don't reults in behavioral changes to userspace, require re-working
>of stap scripts.  Its not the sort of thing that works will for people trying to
>build applications.

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.

Lets imaging the following (I construct one example, but this may universal):
imagine we have two retransmission functions, one for RTO triggered
retransmission and one for dup-ack fast-retransmission. Both functions where
instrumented as tracepoints for years. After some years someone say "hey both
functions are similar, lets fix this and make one function". What should
happened with the tracepoints? Should they merged into one? What should be the
name of the tracepoint?

In the end you will end up fixing userspace analysis tools as well! IMHO there
is - in my opinion - no clean way to add tracepoints and think you are free of
maintaining the whole chain, from kernelspace to userspace.

Only "stable" in kernel API's may be a candidate for tracepoints (like kmalloc
and friends). Highly dynamic and often changed code not.

The biggest advantage from tracepoints is that the function is "annotated"
with something like "this is a tracepoint, please be nice and don't break the
behavioral meaning of this function". On the other side this is also a
disadvantage because it elevates a kernel function to a "userspace API": Tools
will start using this tracepoint, you may end up in a situation where you
can't change/delete tracepoints.

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