1. 23 Jan, 2018 7 commits
  2. 16 Jan, 2018 3 commits
    • Eric W. Biederman's avatar
      ptrace: Use copy_siginfo in setsiginfo and getsiginfo · 0752d7bf
      Eric W. Biederman authored
      
      
      Now that copy_siginfo copies all of the fields this is safe, safer (as
      all of the bits are guaranteed to be copied), clearer, and less error
      prone than using a structure copy.
      Signed-off-by: default avatar"Eric W. Biederman" <ebiederm@xmission.com>
      0752d7bf
    • Eric W. Biederman's avatar
      signal: Unify and correct copy_siginfo_to_user32 · ea64d5ac
      Eric W. Biederman authored
      
      
      Among the existing architecture specific versions of
      copy_siginfo_to_user32 there are several different implementation
      problems.  Some architectures fail to handle all of the cases in in
      the siginfo union.  Some architectures perform a blind copy of the
      siginfo union when the si_code is negative.  A blind copy suggests the
      data is expected to be in 32bit siginfo format, which means that
      receiving such a signal via signalfd won't work, or that the data is
      in 64bit siginfo and the code is copying nonsense to userspace.
      
      Create a single instance of copy_siginfo_to_user32 that all of the
      architectures can share, and teach it to handle all of the cases in
      the siginfo union correctly, with the assumption that siginfo is
      stored internally to the kernel is 64bit siginfo format.
      
      A special case is made for x86 x32 format.  This is needed as presence
      of both x32 and ia32 on x86_64 results in two different 32bit signal
      formats.  By allowing this small special case there winds up being
      exactly one code base that needs to be maintained between all of the
      architectures.  Vastly increasing the testing base and the chances of
      finding bugs.
      
      As the x86 copy of copy_siginfo_to_user32 the call of the x86
      signal_compat_build_tests were moved into sigaction_compat_abi, so
      that they will keep running.
      Signed-off-by: default avatar"Eric W. Biederman" <ebiederm@xmission.com>
      ea64d5ac
    • Eric W. Biederman's avatar
      signal: Remove the code to clear siginfo before calling copy_siginfo_from_user32 · eb5346c3
      Eric W. Biederman authored
      
      
      The new unified copy_siginfo_from_user32 takes care of this.
      Signed-off-by: default avatar"Eric W. Biederman" <ebiederm@xmission.com>
      eb5346c3
  3. 15 Jan, 2018 9 commits
  4. 12 Jan, 2018 21 commits
    • Al Viro's avatar
      signal: kill __ARCH_SI_UID_T · 4795477b
      Al Viro authored
      
      
      it's always __kernel_uid32_t
      Signed-off-by: default avatarAl Viro <viro@zeniv.linux.org.uk>
      Signed-off-by: default avatarEric W. Biederman <ebiederm@xmission.com>
      4795477b
    • Eric W. Biederman's avatar
      signal: Remove unnecessary ifdefs now that there is only one struct siginfo · 0326e7ef
      Eric W. Biederman authored
      
      
      Remove HAVE_ARCH_SIGINFO_T
      Remove __ARCH_SIGSYS
      Signed-off-by: default avatar"Eric W. Biederman" <ebiederm@xmission.com>
      0326e7ef
    • Al Viro's avatar
      signal/mips: switch mips to generic siginfo · 09d1415d
      Al Viro authored
      
      
      ... having taught the latter that si_errno and si_code might be
      swapped.
      Signed-off-by: default avatarAl Viro <viro@zeniv.linux.org.uk>
      Signed-off-by: default avatarEric W. Biederman <ebiederm@xmission.com>
      09d1415d
    • Eric W. Biederman's avatar
    • Eric W. Biederman's avatar
      ia64/signal: switch to generic struct siginfo · 2eb50e2e
      Eric W. Biederman authored
      
      
      ... at a cost of added small ifdef __ia64__ in asm-generic siginfo.h,
      that is.
      
      -- EWB Corrected the comment on _flags to reflect the move
      Signed-off-by: default avatarAl Viro <viro@zeniv.linux.org.uk>
      Signed-off-by: default avatar"Eric W. Biederman" <ebiederm@xmission.com>
      2eb50e2e
    • Eric W. Biederman's avatar
      signal: Remove _sys_private and _overrun_incr from struct compat_siginfo · 2f82a46f
      Eric W. Biederman authored
      
      
      We have never passed either field to or from userspace so just remove them.
      Signed-off-by: default avatar"Eric W. Biederman" <ebiederm@xmission.com>
      2f82a46f
    • Eric W. Biederman's avatar
      signal: Clear si_sys_private before copying siginfo to userspace · 9943d3ac
      Eric W. Biederman authored
      
      
      In preparation for unconditionally copying the whole of siginfo
      to userspace clear si_sys_private.  So this kernel internal
      value is guaranteed not to make it to userspace.
      Signed-off-by: default avatar"Eric W. Biederman" <ebiederm@xmission.com>
      9943d3ac
    • Eric W. Biederman's avatar
    • Eric W. Biederman's avatar
      signal: Document glibc's si_code of SI_ASYNCNL · 75c0abb8
      Eric W. Biederman authored
      
      
      The header uapi/asm-generic/siginfo.h appears to the the repository of
      all of these definitions in linux so collect up glibcs additions as
      well.  Just to prevent someone from accidentally creating a conflict
      in the future.
      Signed-off-by: default avatar"Eric W. Biederman" <ebiederm@xmission.com>
      75c0abb8
    • Eric W. Biederman's avatar
    • Eric W. Biederman's avatar
    • Eric W. Biederman's avatar
      x86/mm/pkeys: Fix fill_sig_info_pkey · 90bc9fb1
      Eric W. Biederman authored
      SEGV_PKUERR is a signal specific si_code which happens to have the
      same numeric value as several others: BUS_MCEERR_AR, ILL_ILLTRP,
      FPE_FLTOVF, TRAP_HWBKPT, CLD_TRAPPED, POLL_ERR, SEGV_THREAD_ID,
      as such it is not safe to just test the si_code the signal number
      must also be tested to prevent a false positive in fill_sig_info_pkey.
      
      I found this error by inspection, and BUS_MCEERR_AR appears to
      be a real candidate for confusion.  So pass in si_signo and fix it.
      
      Cc: Dave Hansen <dave.hansen@linux.intel.com>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Ingo Molnar <mingo@kernel.org>
      Fixes: 019132ff
      
       ("x86/mm/pkeys: Fill in pkey field in siginfo")
      Signed-off-by: default avatar"Eric W. Biederman" <ebiederm@xmission.com>
      90bc9fb1
    • Eric W. Biederman's avatar
      mn10300/misalignment: Use SIGSEGV SEGV_MAPERR to report a failed user copy · 6ac1dc73
      Eric W. Biederman authored
      Setting si_code to 0 is the same a setting si_code to SI_USER which is definitely
      not correct.  With si_code set to SI_USER si_pid and si_uid will be copied to
      userspace instead of si_addr.  Which is very wrong.
      
      So fix this by using a sensible si_code (SEGV_MAPERR) for this failure.
      
      Cc: stable@vger.kernel.org
      Fixes: b920de1b
      
       ("mn10300: add the MN10300/AM33 architecture to the kernel")
      Cc: David Howells <dhowells@redhat.com>
      Cc: Masakazu Urade <urade.masakazu@jp.panasonic.com>
      Cc: Koichi Yasutake <yasutake.koichi@jp.panasonic.com>
      Signed-off-by: default avatar"Eric W. Biederman" <ebiederm@xmission.com>
      6ac1dc73
    • Eric W. Biederman's avatar
      signal: Ensure generic siginfos the kernel sends have all bits initialized · faf1f22b
      Eric W. Biederman authored
      
      
      Call clear_siginfo to ensure stack allocated siginfos are fully
      initialized before being passed to the signal sending functions.
      
      This ensures that if there is the kind of confusion documented by
      TRAP_FIXME, FPE_FIXME, or BUS_FIXME the kernel won't send unitialized
      data to userspace when the kernel generates a signal with SI_USER but
      the copy to userspace assumes it is a different kind of signal, and
      different fields are initialized.
      
      This also prepares the way for turning copy_siginfo_to_user
      into a copy_to_user, by removing the need in many cases to perform
      a field by field copy simply to skip the uninitialized fields.
      Signed-off-by: default avatar"Eric W. Biederman" <ebiederm@xmission.com>
      faf1f22b
    • Eric W. Biederman's avatar
      signal: Introduce clear_siginfo · 8c5dbf2a
      Eric W. Biederman authored
      
      
      Unfortunately struct siginfo has holes both in the common part of the
      structure, in the union members, and in the lack of padding of the
      union members.  The result of those wholes is that the C standard does
      not guarantee those bits will be initialized.  As struct siginfo is
      for communication between the kernel and userspace that is a problem.
      
      Add the helper function clear_siginfo that is guaranteed to clear all of
      the bits in struct siginfo so when the structure is copied there is no danger
      of copying old kernel data and causing a leak of information from kernel
      space to userspace.
      Signed-off-by: default avatar"Eric W. Biederman" <ebiederm@xmission.com>
      8c5dbf2a
    • Eric W. Biederman's avatar
      signal: Reduce copy_siginfo to just a memcpy · 8c36fdf5
      Eric W. Biederman authored
      
      
      The savings for copying just part of struct siginfo appears to be in the
      noise on modern machines.  So remove this ``optimization'' and simplify the code.
      
      At the same time mark the second parameter as constant so there is no confusion
      as to which direction the copy will go.
      
      This ensures that a fully initialized siginfo that is sent ends up as
      a fully initialized siginfo on the signal queue.  This full initialization
      ensures even confused code won't copy unitialized data to userspace, and
      it prepares for turning copy_siginfo_to_user into a simple copy_to_user.
      Signed-off-by: default avatar"Eric W. Biederman" <ebiederm@xmission.com>
      8c36fdf5
    • Eric W. Biederman's avatar
      signal/arm: Document conflicts with SI_USER and SIGFPE · 7771c664
      Eric W. Biederman authored
      Setting si_code to 0 results in a userspace seeing an si_code of 0.
      This is the same si_code as SI_USER.  Posix and common sense requires
      that SI_USER not be a signal specific si_code.  As such this use of 0
      for the si_code is a pretty horribly broken ABI.
      
      Further use of si_code == 0 guaranteed that copy_siginfo_to_user saw a
      value of __SI_KILL and now sees a value of SIL_KILL with the result
      that uid and pid fields are copied and which might copying the si_addr
      field by accident but certainly not by design.  Making this a very
      flakey implementation.
      
      Utilizing FPE_FIXME, siginfo_layout will now return SIL_FAULT and the
      appropriate fields will be reliably copied.
      
      Possible ABI fixes includee:
      - Send the signal without siginfo
      - Don't generate a signal
      - Possibly assign and use an appropriate si_code
      - Don't handle cases which can't happen
      
      Cc: Russell King <rmk@flint.arm.linux.org.uk>
      Cc: linux-arm-kernel@lists.infradead.org
      Ref: 451436b7bbb2 ("[ARM] Add support code for ARM hardware vector floating point")
      History Tree: https://git.kernel.org/pub/scm/linux/kernel/git/tglx/history.git
      
      Signed-off-by: default avatar"Eric W. Biederman" <ebiederm@xmission.com>
      7771c664
    • Eric W. Biederman's avatar
      signal/arm64: Document conflicts with SI_USER and SIGFPE,SIGTRAP,SIGBUS · 526c3ddb
      Eric W. Biederman authored
      Setting si_code to 0 results in a userspace seeing an si_code of 0.
      This is the same si_code as SI_USER.  Posix and common sense requires
      that SI_USER not be a signal specific si_code.  As such this use of 0
      for the si_code is a pretty horribly broken ABI.
      
      Further use of si_code == 0 guaranteed that copy_siginfo_to_user saw a
      value of __SI_KILL and now sees a value of SIL_KILL with the result
      that uid and pid fields are copied and which might copying the si_addr
      field by accident but certainly not by design.  Making this a very
      flakey implementation.
      
      Utilizing FPE_FIXME, BUS_FIXME, TRAP_FIXME siginfo_layout will now return
      SIL_FAULT and the appropriate fields will be reliably copied.
      
      But folks this is a new and unique kind of bad.  This is massively
      untested code bad.  This is inventing new and unique was to get
      siginfo wrong bad.  This is don't even think about Posix or what
      siginfo means bad.  This is lots of eyeballs all missing the fact
      that the code does the wrong thing bad.  This is getting stuck
      and keep making the same mistake bad.
      
      I really hope we can find a non userspace breaking fix for this on a
      port as new as arm64.
      
      Possible ABI fixes include:
      - Send the signal without siginfo
      - Don't generate a signal
      - Possibly assign and use an appropriate si_code
      - Don't handle cases which can't happen
      
      Cc: Catalin Marinas <catalin.marinas@arm.com>
      Cc: Will Deacon <will.deacon@arm.com>
      Cc: Tyler Baicar <tbaicar@codeaurora.org>
      Cc: James Morse <james.morse@arm.com>
      Cc: Tony Lindgren <tony@atomide.com>
      Cc: Nicolas Pitre <nico@linaro.org>
      Cc: Olof Johansson <olof@lixom.net>
      Cc: Santosh Shilimkar <santosh.shilimkar@ti.com>
      Cc: Arnd Bergmann <arnd@arndb.de>
      Cc: linux-arm-kernel@lists.infradead.org
      Ref: 53631b54 ("arm64: Floating point and SIMD")
      Ref: 32015c23 ("arm64: exception: handle Synchronous External Abort")
      Ref: 1d18c47c
      
       ("arm64: MMU fault handling and page table management")
      Signed-off-by: default avatar"Eric W. Biederman" <ebiederm@xmission.com>
      526c3ddb
    • Eric W. Biederman's avatar
      signal/powerpc: Document conflicts with SI_USER and SIGFPE and SIGTRAP · cf4674c4
      Eric W. Biederman authored
      Setting si_code to 0 results in a userspace seeing an si_code of 0.
      This is the same si_code as SI_USER.  Posix and common sense requires
      that SI_USER not be a signal specific si_code.  As such this use of 0
      for the si_code is a pretty horribly broken ABI.
      
      Further use of si_code == 0 guaranteed that copy_siginfo_to_user saw a
      value of __SI_KILL and now sees a value of SIL_KILL with the result
      that uid and pid fields are copied and which might copying the si_addr
      field by accident but certainly not by design.  Making this a very
      flakey implementation.
      
      Utilizing FPE_FIXME and TRAP_FIXME, siginfo_layout() will now return
      SIL_FAULT and the appropriate fields will be reliably copied.
      
      Possible ABI fixes includee:
      - Send the signal without siginfo
      - Don't generate a signal
      - Possibly assign and use an appropriate si_code
      - Don't handle cases which can't happen
      Cc: Paul Mackerras <paulus@samba.org>
      Cc: Kumar Gala <kumar.gala@freescale.com>
      Cc: Michael Ellerman <mpe@ellerman.id.au>
      Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
      Cc:  linuxppc-dev@lists.ozlabs.org
      Ref: 9bad068c24d7 ("[PATCH] ppc32: support for e500 and 85xx")
      Ref: 0ed70f6105ef ("PPC32: Provide proper siginfo information on various exceptions.")
      History Tree: https://git.kernel.org/pub/scm/linux/kernel/git/tglx/history.git
      
      Signed-off-by: default avatar"Eric W. Biederman" <ebiederm@xmission.com>
      cf4674c4
    • Eric W. Biederman's avatar
      signal/metag: Document a conflict with SI_USER with SIGFPE · b80328be
      Eric W. Biederman authored
      Setting si_code to 0 results in a userspace seeing an si_code of 0.
      This is the same si_code as SI_USER.  Posix and common sense requires
      that SI_USER not be a signal specific si_code.  As such this use of 0
      for the si_code is a pretty horribly broken ABI.
      
      Further use of si_code == 0 guaranteed that copy_siginfo_to_user saw a
      value of __SI_KILL and now sees a value of SIL_KILL with the result
      hat uid and pid fields are copied and which might copying the si_addr
      field by accident but certainly not by design.  Making this a very
      flakey implementation.
      
      Utilizing FPE_FIXME siginfo_layout will now return SIL_FAULT and the
      appropriate fields will reliably be copied.
      
      Possible ABI fixes includee:
        - Send the signal without siginfo
        - Don't generate a signal
        - Possibly assign and use an appropriate si_code
        - Don't handle cases which can't happen
      
      Cc: James Hogan <james.hogan@imgtec.com>
      Cc: linux-metag@vger.kernel.org
      Ref: ac919f08
      
       ("metag: Traps")
      Signed-off-by: default avatar"Eric W. Biederman" <ebiederm@xmission.com>
      b80328be
    • Eric W. Biederman's avatar
      signal/parisc: Document a conflict with SI_USER with SIGFPE · b5daf2b9
      Eric W. Biederman authored
      Setting si_code to 0 results in a userspace seeing an si_code of 0.
      This is the same si_code as SI_USER.  Posix and common sense requires
      that SI_USER not be a signal specific si_code.  As such this use of 0
      for the si_code is a pretty horribly broken ABI.
      
      Further use of si_code == 0 guaranteed that copy_siginfo_to_user saw a
      value of __SI_KILL and now sees a value of SIL_KILL with the result
      that uid and pid fields are copied and which might copying the si_addr
      field by accident but certainly not by design.  Making this a very
      flakey implementation.
      
      Utilizing FPE_FIXME siginfo_layout will now return SIL_FAULT and the
      appropriate fields will reliably be copied.
      
      This bug is 13 years old and parsic machines are no longer being built
      so I don't know if it possible or worth fixing it.  But it is at least
      worth documenting this so other architectures don't make the same
      mistake.
      
      Possible ABI fixes includee:
        - Send the signal without siginfo
        - Don't generate a signal
        - Possibly assign and use an appropriate si_code
        - Don't handle cases which can't happen
      
      Cc: "James E.J. Bottomley" <jejb@parisc-linux.org>
      Cc: Helge Deller <deller@gmx.de>
      Cc: linux-parisc@vger.kernel.org
      Ref: 313c01d3e3fd ("[PATCH] PA-RISC update for 2.6.0")
      Histroy Tree: https://git.kernel.org/pub/scm/linux/kernel/git/tglx/history.git
      
      Signed-off-by: default avatar"Eric W. Biederman" <ebiederm@xmission.com>
      b5daf2b9