netdev - Re: [patch 37/37] LTTng instrumentation net

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] [day] [month] [year] [list]

Date:	Thu, 24 Apr 2008 20:30:56 +0400
From:	Pavel Emelyanov <xemul@...nvz.org>
To:	Mathieu Desnoyers <mathieu.desnoyers@...ymtl.ca>
CC:	akpm@...ux-foundation.org, Ingo Molnar <mingo@...e.hu>,
	linux-kernel@...r.kernel.org, netdev@...r.kernel.org
Subject: Re: [patch 37/37] LTTng instrumentation net

Mathieu Desnoyers wrote:
> * Pavel Emelyanov (xemul@...nvz.org) wrote:
>> Mathieu Desnoyers wrote:
>>> Network core events.
>>>
>>> Added markers :
>>>
>>> net_del_ifa_ipv4
>>> net_dev_receive
>>> net_dev_xmit
>>> net_insert_ifa_ipv4
>>> net_socket_call
>>> net_socket_create
>>> net_socket_recvmsg
>>> net_socket_sendmsg
>> Network "core" events are not limited with the above calls.
>>
> 
> True. This is by no mean an exhaustive list of network events. It just
> happens to be the ones which has been useful to LTT/LTTng users for the
> past ~10 years.

Do you mean, that we'll have these debris all over the networking code some day?

>> Besides, real "core" events already sent notifications about themselves.
>> Why do we need additional hooks?
>>
> 
> I doubt the current notification hooks have a performance impact as
> small as the proposed markers. Which notification mechanism do you refer
> to ? It could be interesting to put markers in there instead.

E.g. call_netdevice_notifiers and co. 
And they have nothing to do with performance, since configuration code is 
not supposed to have a rocket speed.

> The goal behind this is to feed information to a general purpose tracer
> like lttng, a scripting mechanism like systemtap or a special-purpose
> tracer like ftrace.
> 
> I think that the most important instrumentation in this patchset is the
> xmit/recv of a packet at the device level. The net_socket_*
> instrumentation could eventually be replaced by an architecture specfic
> system call parameters instrumentation.

I will not argue about the value of such hooks in xmit/recv paths, but
as far as the net_socket_xxx is concerned - there is already the
* ptrace
* security
* kprobes
way to screw the normal code flow up in these places.

> Mathieu
> 
>>> Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@...ymtl.ca>
>>> CC: netdev@...r.kernel.org
>>> ---
>>>  net/core/dev.c     |    6 ++++++
>>>  net/ipv4/devinet.c |    6 ++++++
>>>  net/socket.c       |   19 +++++++++++++++++++
>>>  3 files changed, 31 insertions(+)
> 

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