1. 07 Nov, 2005 1 commit
  2. 31 Oct, 2005 1 commit
  3. 09 Sep, 2005 1 commit
    • Andrea Arcangeli's avatar
      [PATCH] i386: seccomp fix for auditing/ptrace · 4c7fc722
      Andrea Arcangeli authored
      
      
      This is the same issue as ppc64 before, when returning to userland we
      shouldn't re-compute the seccomp check or the task could be killed during
      sigreturn when orig_eax is overwritten by the sigreturn syscall.  This was
      found by Roland.
      
      This was harmless from a security standpoint, but some i686 users reported
      failures with auditing enabled system wide (some distro surprisingly makes
      it the default) and I reproduced it too by keeping the whole workload under
      strace -f.
      
      Patch is tested and works for me under strace -f.
      
      nobody@athlon:~/cpushare> strace -o /tmp/o -f python seccomp_test.py
      make: Nothing to be done for `seccomp_test'.
      Starting computing some malicious bytecode
      init
      load
      start
      stop
      receive_data failure
      kill
      exit_code 0 signal 9
      The malicious bytecode has been killed successfully by seccomp
      Starting computing some safe bytecode
      init
      load
      start
      stop
      174 counts
      kill
      exit_code 0 signal 0
      The seccomp_test.py completed successfully, thank you for testing.
      
      (akpm: collaterally cleaned up a bit of do_syscall_trace() too)
      Signed-off-by: default avatarAndrea Arcangeli <andrea@cpushare.com>
      Signed-off-by: default avatarAndrew Morton <akpm@osdl.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
      4c7fc722
  4. 05 Sep, 2005 5 commits
    • Bodo Stroesser's avatar
      [PATCH] SYSEMU: fix sysaudit / singlestep interaction · ab1c23c2
      Bodo Stroesser authored
      
      
            Paolo 'Blaisorblade' Giarrusso <blaisorblade@yahoo.it>
      
      This is simply an adjustment for "Ptrace - i386: fix Syscall Audit interaction
      with singlestep" to work on top of SYSEMU patches, too.  On this patch, I have
      some doubts: I wonder why we need to alter that way ptrace_disable().
      
      I left the patch this way because it has been extensively tested, but I don't
      understand the reason.
      
      The current PTRACE_DETACH handling simply clears child->ptrace; actually this
      is not enough because entry.S just looks at the thread_flags; actually,
      do_syscall_trace checks current->ptrace but I don't think depending on that is
      good, at least for performance, so I think the clearing is done elsewhere.
      For instance, on PTRACE_CONT it's done, but doing PTRACE_DETACH without
      PTRACE_CONT is possible (and happens when gdb crashes and one kills it
      manually).
      Signed-off-by: default avatarPaolo 'Blaisorblade' Giarrusso <blaisorblade@yahoo.it>
      CC: Roland McGrath <roland@redhat.com>
      Cc: Jeff Dike <jdike@addtoit.com>
      Signed-off-by: default avatarAndrew Morton <akpm@osdl.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
      ab1c23c2
    • Bodo Stroesser's avatar
      [PATCH] Uml support: add PTRACE_SYSEMU_SINGLESTEP option to i386 · 1b38f006
      Bodo Stroesser authored
      
      
      This patch implements the new ptrace option PTRACE_SYSEMU_SINGLESTEP, which
      can be used by UML to singlestep a process: it will receive SINGLESTEP
      interceptions for normal instructions and syscalls, but syscall execution will
      be skipped just like with PTRACE_SYSEMU.
      Signed-off-by: default avatarBodo Stroesser <bstroesser@fujitsu-siemens.com>
      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>
      1b38f006
    • Bodo Stroesser's avatar
      [PATCH] Uml support: reorganize PTRACE_SYSEMU support · c8c86cec
      Bodo Stroesser authored
      
      
      With this patch, we change the way we handle switching from PTRACE_SYSEMU to
      PTRACE_{SINGLESTEP,SYSCALL}, to free TIF_SYSCALL_EMU from double use as a
      preparation for PTRACE_SYSEMU_SINGLESTEP extension, without changing the
      behavior of the host kernel.
      Signed-off-by: default avatarBodo Stroesser <bstroesser@fujitsu-siemens.com>
      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>
      c8c86cec
    • 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().
      
      * We're combining TIF_SYSCALL_EMU with TIF_SYSCALL_TRACE or TIF_SINGLESTEP
        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
        patches.
      
      * 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
        crashes.
      
        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
        interception.
      
        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
      PTRACE_SYSCALL_EMU to PTRACE_SYSCALL_TRACE.
      
      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>
      ed75e8d5
    • Bodo Stroesser's avatar
      [PATCH] Ptrace/i386: fix "syscall audit" interaction with singlestep · 94c80b25
      Bodo Stroesser authored
      
      
            Paolo 'Blaisorblade' Giarrusso <blaisorblade@yahoo.it>
      
      Avoid giving two traps for singlestep instead of one, when syscall auditing is
      enabled.
      
      In fact no singlestep trap is sent on syscall entry, only on syscall exit, as
      can be seen in entry.S:
      
      # Note that in this mask _TIF_SINGLESTEP is not tested !!! <<<<<<<<<<<<<<
              testb $(_TIF_SYSCALL_TRACE|_TIF_SYSCALL_AUDIT|_TIF_SECCOMP),TI_flags(%ebp)
              jnz syscall_trace_entry
      	...
      syscall_trace_entry:
      	...
      	call do_syscall_trace
      
      But auditing a SINGLESTEP'ed process causes do_syscall_trace to be called, so
      the tracer will get one more trap on the syscall entry path, which it
      shouldn't.
      Signed-off-by: default avatarPaolo 'Blaisorblade' Giarrusso <blaisorblade@yahoo.it>
      CC: Roland McGrath <roland@redhat.com>
      Cc: Jeff Dike <jdike@addtoit.com>
      Signed-off-by: default avatarAndrew Morton <akpm@osdl.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
      94c80b25
  5. 23 Jun, 2005 1 commit
  6. 01 May, 2005 1 commit
  7. 29 Apr, 2005 1 commit
    • 's avatar
      [AUDIT] Don't allow ptrace to fool auditing, log arch of audited syscalls. · 2fd6f58b
      authored
      
      
      We were calling ptrace_notify() after auditing the syscall and arguments,
      but the debugger could have _changed_ them before the syscall was actually
      invoked. Reorder the calls to fix that.
      
      While we're touching ever call to audit_syscall_entry(), we also make it
      take an extra argument: the architecture of the syscall which was made,
      because some architectures allow more than one type of syscall.
      
      Also add an explicit success/failure flag to audit_syscall_exit(), for
      the benefit of architectures which return that in a condition register
      rather than only returning a single register.
      
      Change type of syscall return value to 'long' not 'int'.
      Signed-off-by: default avatarDavid Woodhouse <dwmw2@infradead.org>
      2fd6f58b
  8. 16 Apr, 2005 1 commit
    • Linus Torvalds's avatar
      Linux-2.6.12-rc2 · 1da177e4
      Linus Torvalds authored
      Initial git repository build. I'm not bothering with the full history,
      even though we have it. We can create a separate "historical" git
      archive of that later if we want to, and in the meantime it's about
      3.2GB when imported into git - space that would just make the early
      git days unnecessarily complicated, when we don't have a lot of good
      infrastructure for it.
      
      Let it rip!
      1da177e4