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.
> 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)
|
![[Computer Systems Lab]](http://www.cs.wisc.edu/pics/csl_logo.gif){kind=logo}