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

["H. Peter Anvin" <hpa@zytor.com>]

On 03/29/2012 12:43 PM, Vaibhav Nagarnaik wrote:
> 
> However, we agree that the syscall tracing as implemented currently is
> a bit unwieldy. We would want to be a part of the re-designing effort
> if there is a momentum in the community towards that goal. We would be
> happy to contribute towards this effort.
> 

I had a long discussion with Frederic over IRC earlier today.  We came
up with the following strawman:

1. A system call thunk (which could be enabled/disabled by patching the
syscall table.)  This provides an entry and exit hook, and also sets a
per-thread flag to capture userspace traffic.

2. Instrumenting get_user/put_user/copy_from_user/copy_to_user to
capture traffic to userspace.  This captures the *full* set of system
call arguments, including things addressed via pointers.  Furthermore,
it captures the exact versions fed to or returned from the kernel, and
deals with data-dependent collection like ioctl().

This has to be done with extreme care to avoid introducing overhead in
the no-tracing case, however, as these functions are extraordinarily
performance sensitive.  This probably will require careful patching in
the first enable/last disable case.

3. There will need to be userspace tools written to decode the resulting
trace buffer.  This is pretty much needed anyway, but once you throw in
complex data structures it becomes even more so.  A trace will basically
consist of:

SYSCALL_ENTRY <syscall number> <arg1..6>
COPY_FROM_USER <address> <data>
  ...
COPY_TO_USER <address> <data>
  ...
SYSCALL_EXIT <return value>

Outputting this in human-readable format requires some reasonably
sophisticated logic, but the *HUGE* advantage is that not only is all
the information there, it is *correct by construction*.

	-hpa