Re: [DynInst_API:] Proposal: Add System Call Events to ProcControlAPI

[Emily Jacobson <jacobson@xxxxxxxxxxx>]

On Thu, May 23, 2013 at 11:50 AM, David Smith <dsmith@xxxxxxxxxx> wrote:

On 05/20/2013 09:53 AM, Emily Jacobson wrote:
> Hi all,

Sorry for taking so long to respond to this.

> We’re proposing adding system call callbacks to ProcControlAPI. After
> internal discussion, we're sending out this proposal for wider feedback.
> What follows is an overview of this feature, as well as the proposed
> ProcControlAPI interface. For this feature to be exposed in the
> DyninstAPI interface, it must first be exposed via ProcControlAPI. We
> expect the DyninstAPI interface will closely mirror this.

I've never used the ProcControlAPI interface, but I'll just assume the
DyninstAPI will look the same and go ahead.

... stuff deleted ...

> *Proposed Interface:*

>
>
> A new Event child class: EventSyscall.  An EventSyscall is triggered
> when a thread, which was put in syscall-monitoring mode by
> Thread::setSyscallMode, enters or exists a system call. The Thread will
> remain in syscall-monitoring mode after completion of this event
> (presuming it has not been explicitly disabled by
> Thread::setSyscallMode). An EventSyscall may be associated with an
> EventType of pre-syscall (system call entry) or post-syscall (system
> call exit).

So, Thread::setSyscallMode turns on/off syscall monitoring. When on,
EventSyscall events get seen.

In my head when thinking about this, I would have figured syscall events
would follow more of the existing event handling mechanisms, like
registerThreadEventCallback(). But, perhaps this is the difference
between the ProcControlAPI and DyninstAPI?

> We’re proposing adding a class representation for system calls; we’re
> currently calling this class MachSyscall. Also, in support of this
> syscall representation, we’re proposing representing the cross-product
> of various architecture, OS, and possibly version information in a
> Platform class. In this context, this allows us to go from a syscall’s
> mutatee-side ID to its name (and to its arguments, eventually). More
> generally, it allows us to represent the platform of a mutatee, which
> even with our current feature set is not necessarily the platform of the
> mutator (e.g. 32-bit mutatees/64-bit mutators). As this is variable
> based on the process, it needs to be a process-level piece of
> information and can’t be baked in at compile time.
>
> This interface could be expanded in the future to support argument types
> and value information.

What I'd like to see minimally available when a syscall entry event
happens is the syscall number and raw arguments. On syscall exit I'd
like to see the syscall number and return value.

You'd get bonus points for letting me change the syscall return value
(for failure injection) and letting me change syscall argument values.

But, perhaps that just betrays the fact that I'm used to working in the
kernel. Just for reference's sake, here is the kernel API systemtap used
in the past (things have changed a bit for newer kernels using tracepoints):

<https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/include/asm-generic/syscall.h>

I'm sure you already know this, but argument handling is tricky and very
architecture dependent. On some platforms, all args are passed in
registers. On other platforms, the first N arguments are stored in
registers, and the rest on the stack. Be sure your interface is flexible
enough to handle both cases.

Once you get past the minimum information needed, comes a design
question. Who is responsible for *really* understanding the syscalls,
information like number of arguments and argument types? Is it dyninst
or the software built on top of dyninst? (I don't have an answer here,
just asking the question.)

In the case of systemtap, since we're trying to keep our interface
similar between our in-kernel and our userspace (dyninst) runtimes,
we'll most likely just provide raw values and let the user figure out
how to interpret the system call.

Interpreting all system calls could be a big job.

In our initial implementation, we are not planning on providing argument access (raw values or otherwise), partly due to the complexities you mention. Currently, users may use raw memory and register access (available via existing API calls) to read system call arguments. Software built on top of Dyninst would be responsible for understanding system call semantics. If Dyninst were to provide argument access in the future, we would like to represent syscall arguments in the same form as our existing function parameter access (i.e., BPatch_paramExpr).

As for changing system call return values, we had not previously considered this feature. We could expose this with the ability to specify a new integer return value. However, I’m not sure we’d reasonably be able to provide semantic information for return values or return value modification. 

... stuff deleted ...

> // Returns the platform-specific number for this system call
>
> int num() const;
>
>
> // Returns the name for this system call (e.g., “getpid”)
>
> string name() const;

That's a useful feature, providing the syscall name. We've had a bug
open in systemtap for a long while asking for this feature, but no one
has found the time to implement it.

--
David Smith
dsmith@xxxxxxxxxx
Red Hat
http://www.redhat.com
256.217.0141 (direct)
256.837.0057 (fax)