linux-kernel - Re: [RFC] Userspace tracing memory mappings

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]

Message-ID: <20080123215537.GC2282@Krystal>
Date:	Wed, 23 Jan 2008 16:55:37 -0500
From:	Mathieu Desnoyers <mathieu.desnoyers@...ymtl.ca>
To:	"Frank Ch. Eigler" <fche@...hat.com>
Cc:	Dave Hansen <haveblue@...ibm.com>, mbligh@...gle.com,
	linux-mm@...ck.org, linux-kernel@...r.kernel.org
Subject: Re: [RFC] Userspace tracing memory mappings

* Frank Ch. Eigler (fche@...hat.com) wrote:
> Mathieu Desnoyers <mathieu.desnoyers@...ymtl.ca> writes:
> 
> > [...]  Since memory management is not my speciality, I would like to
> > know if there are some implementation details I should be aware of
> > for my LTTng userspace tracing buffers. Here is what I want to do
> > [...]
> 
> Would you mind offering some justification for requiring a kernel
> extension for user-space tracing?  What can the kernel enable in this
> context that a user-space library (which you already assume will be
> linked in) can't?
> 
> - FChE

The kernel would provide :

- System-wide activation of markers located in userspace code
  example use : libc, NPTL tracing.
- Ability to extract buffers of a crashed process
- Ability to extract userspace tracing buffers upon kernel crash
- Activation of userspace tracing at the same time as the kernel tracing
  activation is done, without requiring messing up with signals.
- Potentially filtering on events coming from userspace, without messing
  up with signals.

Another point is early boot tracing : tracing processes such as init
requires to use syscalls rather than relying on debugfs/dev/proc file
operations. And we can't dump the information to the disk yet, so we
cannot expect the process itself to deal with file opening or socket
opening that soon. Therefore, we have to divide tracing in two distinct
actions : writing to the buffers and dumping the buffers (to disk or
though the network).

Another reason why we don't want to do everything is a single library is
that it would account the disk write time to the traced process. If we
do this from the kernel, we can know how many time it took because we
trace it. Another, better yet, reason for this is that if we want to
extract the data to disk or through the network, and want to get the
last trace bits of a segfaulted process, we have to share the buffers
with another process somehow. However, creating one extra process per
traced process is kind of awkward.

So the code itself would be a library in userspace. However, it would
interact both with the kernel for trace activation and with a daemon to
extract the information to disk or to the network. I start to think that
a userspace library would be sufficient for the userspace part of this
design (no need to modify vDSO).

And system V shared memory has a limit on the number of such memory
mapping one can have in the system that is way too low.

Does it explain the purpose of the kernel interaction better ?

Mathieu

-- 
Mathieu Desnoyers
Computer Engineering Ph.D. Student, Ecole Polytechnique de Montreal
OpenPGP key fingerprint: 8CD5 52C3 8E3C 4140 715F  BA06 3F25 A8FE 3BAE 9A68
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/