linux-kernel - Re: [RFC][PATCH 0/2] Syscalls tracing

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]

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/