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]
Message-ID: <20090308112440.GB5000@nowhere>
Date:	Sun, 8 Mar 2009 12:24:41 +0100
From:	Frederic Weisbecker <fweisbec@...il.com>
To:	Peter Zijlstra <peterz@...radead.org>
Cc:	Ingo Molnar <mingo@...e.hu>, LKML <linux-kernel@...r.kernel.org>,
	Lai Jiangshan <laijs@...fujitsu.com>,
	Steven Rostedt <rostedt@...dmis.org>,
	Mathieu Desnoyers <mathieu.desnoyers@...ymtl.ca>,
	Jiaying Zhang <jiayingz@...gle.com>,
	Martin Bligh <mbligh@...gle.com>,
	Arjan van de Ven <arjan@...radead.org>
Subject: Re: [RFC][PATCH 0/2] Syscalls tracing

On Sat, Mar 07, 2009 at 05:02:47PM +0100, Frederic Weisbecker wrote:
> On Sat, Mar 07, 2009 at 01:15:18PM +0100, Peter Zijlstra wrote:
> > On Sat, 2009-03-07 at 05:52 +0100, Frederic Weisbecker wrote:
> > > Here is a first attempt, quick one-shot, to provide a syscall tracing
> > > infrastructure on ftrace.
> > > 
> > > The RFC prefix is here to reflect its ugliness on various parts.
> > > The compromise between tracing reliabilty and speed is hard to balance.
> > > For example I guess the basic and horrid string mask should be dropped in favour
> > > of something else, which takes care of the volatile strings from the userspace.
> > > 
> > > But I hope a lot of ideas to make it better will come along this discussion.
> > 
> > Can't you abuse the SYSCALL_DEFINE macros? This current approach looks
> > like it will replicate the syscall table.
> > 
> 
> 
> Ah, I did not even think about it.
> I will be able to get the number of parameters. Sounds good. But I will
> still need a way to store their format somewhere.
>

Ok, we can iterate through sections datas for each one and then generate the format string
depending of the types of the parameters. We can even to it once at boot time.
The last thing is the need to match the exact syscall entry from this section when we enter
a syscall. Don't know yet how I will do that but I will think about it.

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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ