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

[Emily Jacobson <jacobson@xxxxxxxxxxx>]

On Thu, May 23, 2013 at 4:40 PM, David Smith <dsmith@xxxxxxxxxx> wrote:

On 05/23/2013 02:35 PM, Emily Jacobson wrote:
>
> On Thu, May 23, 2013 at 11:50 AM, David Smith <dsmith@xxxxxxxxxx

> <mailto: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).

Hmm. Wouldn't you need to keep up with all syscalls yourself here to
provide typed parameter access? There isn't any dwarf info here, right?
That's a big job, especially considering arch-specific syscalls and
32-bit-on-64-bit executables. If you haven't already, take a look at the
source to strace.

Yes, if Dyninst were to provide argument access, we would need to support that level of semantic information; I definitely agree that this would be a big task. That added complexity is a large part of the reason argument access is a hypothetical future feature and not intended to be part of this initial interface and implementation.

 

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

This feature would be a "nice to have", not really a "need to have". It
is useful to inject syscall failures - i.e. does my program handle
read/write not returning the full number of bytes requested, does my
program handle EINTR being returned from syscalls, etc.

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