• Laurent Vivier's avatar
    [PATCH] UML Support - Ptrace: adds the host SYSEMU support, for UML and general usage · ed75e8d5
    Laurent Vivier authored
          Jeff Dike <jdike@addtoit.com>,
          Paolo 'Blaisorblade' Giarrusso <blaisorblade_spam@yahoo.it>,
          Bodo Stroesser <bstroesser@fujitsu-siemens.com>
    Adds a new ptrace(2) mode, called PTRACE_SYSEMU, resembling PTRACE_SYSCALL
    except that the kernel does not execute the requested syscall; this is useful
    to improve performance for virtual environments, like UML, which want to run
    the syscall on their own.
    In fact, using PTRACE_SYSCALL means stopping child execution twice, on entry
    and on exit, and each time you also have two context switches; with SYSEMU you
    avoid the 2nd stop and so save two context switches per syscall.
    Also, some architectures don't have support in the host for changing the
    syscall number via ptrace(), which is currently needed to skip syscall
    execution (UML turns any syscall into getpid() to avoid it being executed on
    the host).  Fixing that is hard, while SYSEMU is easier to implement.
    * This version of the patch includes some suggestions of Jeff Dike to avoid
      adding any instructions to the syscall fast path, plus some other little
      changes, by myself, to make it work even when the syscall is executed with
      SYSENTER (but I'm unsure about them). It has been widely tested for quite a
      lot of time.
    * Various fixed were included to handle the various switches between
      various states, i.e. when for instance a syscall entry is traced with one of
      PT_SYSCALL / _SYSEMU / _SINGLESTEP and another one is used on exit.
      Basically, this is done by remembering which one of them was used even after
      the call to ptrace_notify().
      to make do_syscall_trace() notice that the current syscall was started with
      SYSEMU on entry, so that no notification ought to be done in the exit path;
      this is a bit of a hack, so this problem is solved in another way in next
    * Also, the effects of the patch:
    "Ptrace - i386: fix Syscall Audit interaction with singlestep"
    are cancelled; they are restored back in the last patch of this series.
    Detailed descriptions of the patches doing this kind of processing follow (but
    I've already summed everything up).
    * Fix behaviour when changing interception kind #1.
      In do_syscall_trace(), we check the status of the TIF_SYSCALL_EMU flag
      only after doing the debugger notification; but the debugger might have
      changed the status of this flag because he continued execution with
      PTRACE_SYSCALL, so this is wrong.  This patch fixes it by saving the flag
      status before calling ptrace_notify().
    * Fix behaviour when changing interception kind #2:
      avoid intercepting syscall on return when using SYSCALL again.
      A guest process switching from using PTRACE_SYSEMU to PTRACE_SYSCALL
      The problem is in arch/i386/kernel/entry.S.  The current SYSEMU patch
      inhibits the syscall-handler to be called, but does not prevent
      do_syscall_trace() to be called after this for syscall completion
      The appended patch fixes this.  It reuses the flag TIF_SYSCALL_EMU to
      remember "we come from PTRACE_SYSEMU and now are in PTRACE_SYSCALL", since
      the flag is unused in the depicted situation.
    * Fix behaviour when changing interception kind #3:
      avoid intercepting syscall on return when using SINGLESTEP.
      When testing 2.6.9 and the skas3.v6 patch, with my latest patch and had
      problems with singlestepping on UML in SKAS with SYSEMU.  It looped
      receiving SIGTRAPs without moving forward.  EIP of the traced process was
      the same for all SIGTRAPs.
    What's missing is to handle switching from PTRACE_SYSCALL_EMU to
    PTRACE_SINGLESTEP in a way very similar to what is done for the change from
    I.e., after calling ptrace(PTRACE_SYSEMU), on the return path, the debugger is
    notified and then wake ups the process; the syscall is executed (or skipped,
    when do_syscall_trace() returns 0, i.e.  when using PTRACE_SYSEMU), and
    do_syscall_trace() is called again.  Since we are on the return path of a
    SYSEMU'd syscall, if the wake up is performed through ptrace(PTRACE_SYSCALL),
    we must still avoid notifying the parent of the syscall exit.  Now, this
    behaviour is extended even to resuming with PTRACE_SINGLESTEP.
    Signed-off-by: default avatarPaolo 'Blaisorblade' Giarrusso <blaisorblade@yahoo.it>
    Cc: Jeff Dike <jdike@addtoit.com>
    Signed-off-by: default avatarAndrew Morton <akpm@osdl.org>
    Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
ptrace.c 18.7 KB