linux-kernel - Re: [RFC] convert ftrace syscall tracer to TRACE

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: <20090509142952.GA3511@Krystal>
Date:	Sat, 9 May 2009 10:29:52 -0400
From:	Mathieu Desnoyers <mathieu.desnoyers@...ymtl.ca>
To:	Ingo Molnar <mingo@...e.hu>
Cc:	Frédéric Weisbecker <fweisbec@...il.com>,
	Jason Baron <jbaron@...hat.com>,
	Tom Zanussi <tzanussi@...il.com>, linux-kernel@...r.kernel.org,
	laijs@...fujitsu.com, rostedt@...dmis.org, peterz@...radead.org,
	jiayingz@...gle.com, mbligh@...gle.com, roland@...hat.com,
	fche@...hat.com
Subject: Re: [RFC] convert ftrace syscall tracer to TRACE_EVENT()

* Ingo Molnar (mingo@...e.hu) wrote:
> 
> * Frédéric Weisbecker <fweisbec@...il.com> wrote:
> 
> > > I would expect to use copy_string_from_user (for strings) and 
> > > copy_from_user for structures, because without any strings 
> > > (especially), the trace information become much less useful.
> > 
> > Yeah, for structures we would just need the copy_from_user.
> 
> There's just a few places (mainly related to VFS APIs) where we 
> really want to do that, and there we want to do it a bit later, not 
> at syscall time: we want to do it after the getname(), to output a 
> stable (and already copied to kernel space) copy of the file name.
> 
> So the right solution there would be to add special, case by case 
> tracepoints to those few places. We dont need strings for the 
> majority of the 300+ system calls that exist on Linux.
> 
> 	Ingo

Hrm, this is an important design decision.. I cover a lot of those sites
in my LTTng instrumentation, and this is clearly one way to do it, at
the expense of adding tracepoints in many kernel locations when there
could be a functionnal equivalent with syscall instrumentation.

The thing we would need to do it from the syscall tracing site is a
table to map the system call numbers to their specific types (for the
syscalls we care about) and therefore which would also map to a
serialisation function to extract the parameters and write the correct
content into the trace buffers.

We could also use getname()/putname() in the syscall tracing primitive.
Note that architectures like x86 64 needs some tweaks I have in my
patchset to correctly ensure that syscall entry/exit are always paired.
This is required because we change the thread flag synchronously with
thread execution upen activation/deactivation.

Mathieu

-- 
Mathieu Desnoyers
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/