1. 24 5月, 2018 1 次提交
  2. 15 5月, 2018 1 次提交
  3. 09 11月, 2017 1 次提交
    • J
      MIPS/ptrace: Update syscall nr on register changes · de8cd0dc
      James Hogan 提交于
      Update the thread_info::syscall field when registers are modified via
      ptrace to change or cancel the system call being entered.
      
      This is important to allow seccomp and the syscall entry and exit trace
      events to observe the new syscall number changed by the normal ptrace
      hook or seccomp. That includes allowing seccomp's recheck of the system
      call number after SECCOMP_RET_TRACE to notice if the syscall is changed
      to a denied one, which happens in seccomp since commit ce6526e8
      ("seccomp: recheck the syscall after RET_TRACE") in v4.8.
      
      In the process of doing this, the logic to determine whether an indirect
      system call is in progress (i.e. the O32 ABI's syscall()) is abstracted
      into mips_syscall_is_indirect(), and a new mips_syscall_update_nr() is
      used to update the thread_info::syscall based on the register state.
      
      The following ptrace operations are updated:
       - PTRACE_SETREGS (ptrace_setregs()).
       - PTRACE_SETREGSET with NT_PRSTATUS (gpr32_set() and gpr64_set()).
       - PTRACE_POKEUSR with 2/v0 or 4/a0 for indirect syscall
         ([compat_]arch_ptrace()).
      
      Fixes: c2d9f177 ("MIPS: Fix syscall_get_nr for the syscall exit tracing.")
      Signed-off-by: NJames Hogan <jhogan@kernel.org>
      Cc: Ralf Baechle <ralf@linux-mips.org>
      Cc: Lars Persson <larper@axis.com>
      Cc: Oleg Nesterov <oleg@redhat.com>
      Cc: Kees Cook <keescook@chromium.org>
      Cc: Andy Lutomirski <luto@amacapital.net>
      Cc: Will Drewry <wad@chromium.org>
      Cc: linux-mips@linux-mips.org
      Patchwork: https://patchwork.linux-mips.org/patch/16995/
      de8cd0dc
  4. 02 3月, 2017 1 次提交
  5. 25 12月, 2016 1 次提交
  6. 23 11月, 2016 1 次提交
    • E
      ptrace: Don't allow accessing an undumpable mm · 84d77d3f
      Eric W. Biederman 提交于
      It is the reasonable expectation that if an executable file is not
      readable there will be no way for a user without special privileges to
      read the file.  This is enforced in ptrace_attach but if ptrace
      is already attached before exec there is no enforcement for read-only
      executables.
      
      As the only way to read such an mm is through access_process_vm
      spin a variant called ptrace_access_vm that will fail if the
      target process is not being ptraced by the current process, or
      the current process did not have sufficient privileges when ptracing
      began to read the target processes mm.
      
      In the ptrace implementations replace access_process_vm by
      ptrace_access_vm.  There remain several ptrace sites that still use
      access_process_vm as they are reading the target executables
      instructions (for kernel consumption) or register stacks.  As such it
      does not appear necessary to add a permission check to those calls.
      
      This bug has always existed in Linux.
      
      Fixes: v1.0
      Cc: stable@vger.kernel.org
      Reported-by: NAndy Lutomirski <luto@amacapital.net>
      Signed-off-by: N"Eric W. Biederman" <ebiederm@xmission.com>
      84d77d3f
  7. 19 10月, 2016 1 次提交
  8. 02 8月, 2014 2 次提交
  9. 31 7月, 2014 1 次提交
  10. 01 4月, 2014 1 次提交
  11. 27 3月, 2014 1 次提交
  12. 14 1月, 2014 1 次提交
    • P
      MIPS: Support for 64-bit FP with O32 binaries · 597ce172
      Paul Burton 提交于
      CPUs implementing MIPS32 R2 may include a 64-bit FPU, just as MIPS64 CPUs
      do. In order to preserve backwards compatibility a 64-bit FPU will act
      like a 32-bit FPU (by accessing doubles from the least significant 32
      bits of an even-odd pair of FP registers) when the Status.FR bit is
      zero, again just like a mips64 CPU. The standard O32 ABI is defined
      expecting a 32-bit FPU, however recent toolchains support use of a
      64-bit FPU from an O32 MIPS32 executable. When an ELF executable is
      built to use a 64-bit FPU a new flag (EF_MIPS_FP64) is set in the ELF
      header.
      
      With this patch the kernel will check the EF_MIPS_FP64 flag when
      executing an O32 binary, and set Status.FR accordingly. The addition
      of O32 64-bit FP support lessens the opportunity for optimisation in
      the FPU emulator, so a CONFIG_MIPS_O32_FP64_SUPPORT Kconfig option is
      introduced to allow this support to be disabled for those that don't
      require it.
      
      Inspired by an earlier patch by Leonid Yegoshin, but implemented more
      cleanly & correctly.
      Signed-off-by: NPaul Burton <paul.burton@imgtec.com>
      Cc: linux-mips@linux-mips.org
      Cc: Paul Burton <paul.burton@imgtec.com>
      Patchwork: https://patchwork.linux-mips.org/patch/6154/Signed-off-by: NRalf Baechle <ralf@linux-mips.org>
      597ce172
  13. 01 2月, 2013 1 次提交
  14. 29 3月, 2012 1 次提交
  15. 13 7月, 2009 1 次提交
  16. 11 1月, 2009 1 次提交
  17. 11 10月, 2008 3 次提交
  18. 30 10月, 2007 1 次提交
  19. 12 10月, 2007 1 次提交
  20. 10 10月, 2006 1 次提交
  21. 20 6月, 2006 1 次提交
  22. 19 4月, 2006 1 次提交
  23. 07 2月, 2006 1 次提交
  24. 13 1月, 2006 2 次提交
  25. 10 1月, 2006 1 次提交
    • R
      MIPS: DSP: eleminate used_dsp. · 6c355852
      Ralf Baechle 提交于
          
      used_dsp was meant to be used like used_math - but since the FPU context
      is small and lazy context switching is a stupid idea on multiprocessors
      this idea only got halfway implemented and those bits are were now
      breaking ptrace.
      Signed-off-by: NRalf Baechle <ralf@linux-mips.org>
      6c355852
  26. 09 1月, 2006 1 次提交
  27. 30 10月, 2005 5 次提交
  28. 01 5月, 2005 1 次提交
  29. 17 4月, 2005 1 次提交
    • L
      Linux-2.6.12-rc2 · 1da177e4
      Linus Torvalds 提交于
      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