linux-kernel - Re: [PATCH 4/6] trace: trace syscall in its handler not from ptrace handler

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: <4F714982.6020208@zytor.com>
Date:	Mon, 26 Mar 2012 22:00:50 -0700
From:	"H. Peter Anvin" <hpa@...or.com>
To:	Vaibhav Nagarnaik <vnagarnaik@...gle.com>
CC:	Steven Rostedt <rostedt@...dmis.org>,
	Frederic Weisbecker <fweisbec@...il.com>,
	Thomas Gleixner <tglx@...utronix.de>,
	Ingo Molnar <mingo@...hat.com>,
	David Sharp <dhsharp@...gle.com>,
	Justin Teravest <teravest@...gle.com>,
	Laurent Chavey <chavey@...gle.com>, x86@...nel.org,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH 4/6] trace: trace syscall in its handler not from ptrace
 handler

On 03/26/2012 11:39 AM, Vaibhav Nagarnaik wrote:
> The syscalls are a tricky bunch to trace, because of their multitude and
> dynamic nature of the list. In order to solve this, a macro handled the
> sycalls handler definition and it was expanded into setting up the
> metadata for the syscall event. A handler hooked into the ptrace syscall
> tracer to check whether an invoked syscall was supposed to be traced.
> 
> This added latency to all the invoked syscalls, since they had to be
> checked for tracing and also affected the latency of syscall that was
> actually getting traced. For e.g., using a simple program which invokes
> getuid() in a repeated loop and calculates the average time per syscall
> invocation found a latency of 570 - 117 = 453 ns added to every traced
> syscall.
> 
> This patch changes the syscall macro expansion, to create a function
> that adds the entry and exit tracepoints for the given syscall so that
> the latency can be avoided. This was suggested by Mathieu Desnoyers in
> https://lkml.org/lkml/2010/10/13/337
> 
> After this patch, the latency added is 370 - 117 = 253 ns per invocation
> of a traced syscall. This is on par with a simple tracepoint added to
> any kernel code path.
> 
> This patch also makes syscall tracing architecture independent as there
> is no need to have a hook into the architecture specific syscall tracer
> functions.
> 

I am officially confused here.  You have a single, common, dispatch
point for all system calls -- why don't you use it?  That is of course
the system call table.  If you want to trace a system call, override the
entry point in the syscall table to point to a hook function which can
provide entry and exit hooks.  It's not even code, it's data, so you
don't even have to play the code patching song and dance routine
(although you may have to map it read/write which is normally not the
case for security reasons.)

The best part is that the cost for an untraced system call is *zero*.

	-hpa

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