1. 23 1月, 2018 2 次提交
  2. 17 1月, 2018 1 次提交
  3. 16 1月, 2018 11 次提交
  4. 13 1月, 2018 22 次提交
    • A
      signal: kill __ARCH_SI_UID_T · 4795477b
      Al Viro 提交于
      it's always __kernel_uid32_t
      Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>
      Signed-off-by: NEric W. Biederman <ebiederm@xmission.com>
      4795477b
    • E
      signal: Remove unnecessary ifdefs now that there is only one struct siginfo · 0326e7ef
      Eric W. Biederman 提交于
      Remove HAVE_ARCH_SIGINFO_T
      Remove __ARCH_SIGSYS
      Signed-off-by: N"Eric W. Biederman" <ebiederm@xmission.com>
      0326e7ef
    • A
      signal/mips: switch mips to generic siginfo · 09d1415d
      Al Viro 提交于
      ... having taught the latter that si_errno and si_code might be
      swapped.
      Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>
      Signed-off-by: NEric W. Biederman <ebiederm@xmission.com>
      09d1415d
    • E
    • E
      ia64/signal: switch to generic struct siginfo · 2eb50e2e
      Eric W. Biederman 提交于
      ... 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: NAl Viro <viro@zeniv.linux.org.uk>
      Signed-off-by: N"Eric W. Biederman" <ebiederm@xmission.com>
      2eb50e2e
    • E
      signal: Remove _sys_private and _overrun_incr from struct compat_siginfo · 2f82a46f
      Eric W. Biederman 提交于
      We have never passed either field to or from userspace so just remove them.
      Signed-off-by: N"Eric W. Biederman" <ebiederm@xmission.com>
      2f82a46f
    • E
      signal: Clear si_sys_private before copying siginfo to userspace · 9943d3ac
      Eric W. Biederman 提交于
      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: N"Eric W. Biederman" <ebiederm@xmission.com>
      9943d3ac
    • E
    • E
      signal: Document glibc's si_code of SI_ASYNCNL · 75c0abb8
      Eric W. Biederman 提交于
      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: N"Eric W. Biederman" <ebiederm@xmission.com>
      75c0abb8
    • E
    • E
    • E
      x86/mm/pkeys: Fix fill_sig_info_pkey · 90bc9fb1
      Eric W. Biederman 提交于
      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: N"Eric W. Biederman" <ebiederm@xmission.com>
      90bc9fb1
    • E
      mn10300/misalignment: Use SIGSEGV SEGV_MAPERR to report a failed user copy · 6ac1dc73
      Eric W. Biederman 提交于
      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: N"Eric W. Biederman" <ebiederm@xmission.com>
      6ac1dc73
    • E
      signal: Ensure generic siginfos the kernel sends have all bits initialized · faf1f22b
      Eric W. Biederman 提交于
      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: N"Eric W. Biederman" <ebiederm@xmission.com>
      faf1f22b
    • E
      signal: Introduce clear_siginfo · 8c5dbf2a
      Eric W. Biederman 提交于
      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: N"Eric W. Biederman" <ebiederm@xmission.com>
      8c5dbf2a
    • E
      signal: Reduce copy_siginfo to just a memcpy · 8c36fdf5
      Eric W. Biederman 提交于
      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: N"Eric W. Biederman" <ebiederm@xmission.com>
      8c36fdf5
    • E
      signal/arm: Document conflicts with SI_USER and SIGFPE · 7771c664
      Eric W. Biederman 提交于
      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.gitSigned-off-by: N"Eric W. Biederman" <ebiederm@xmission.com>
      7771c664
    • E
      signal/arm64: Document conflicts with SI_USER and SIGFPE,SIGTRAP,SIGBUS · 526c3ddb
      Eric W. Biederman 提交于
      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: N"Eric W. Biederman" <ebiederm@xmission.com>
      526c3ddb
    • E
      signal/powerpc: Document conflicts with SI_USER and SIGFPE and SIGTRAP · cf4674c4
      Eric W. Biederman 提交于
      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.gitSigned-off-by: N"Eric W. Biederman" <ebiederm@xmission.com>
      cf4674c4
    • E
      signal/metag: Document a conflict with SI_USER with SIGFPE · b80328be
      Eric W. Biederman 提交于
      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: N"Eric W. Biederman" <ebiederm@xmission.com>
      b80328be
    • E
      signal/parisc: Document a conflict with SI_USER with SIGFPE · b5daf2b9
      Eric W. Biederman 提交于
      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.gitSigned-off-by: N"Eric W. Biederman" <ebiederm@xmission.com>
      b5daf2b9
    • E
      signal/openrisc: Fix do_unaligned_access to send the proper signal · 500d5830
      Eric W. Biederman 提交于
      While reviewing the signal sending on openrisc the do_unaligned_access
      function stood out because it is obviously wrong.  A comment about an
      si_code set above when actually si_code is never set.  Leading to a
      random si_code being sent to userspace in the event of an unaligned
      access.
      
      Looking further SIGBUS BUS_ADRALN is the proper pair of signal and
      si_code to send for an unaligned access. That is what other
      architectures do and what is required by posix.
      
      Given that do_unaligned_access is broken in a way that no one can be
      relying on it on openrisc fix the code to just do the right thing.
      
      Cc: stable@vger.kernel.org
      Fixes: 769a8a96 ("OpenRISC: Traps")
      Cc: Jonas Bonn <jonas@southpole.se>
      Cc: Stefan Kristiansson <stefan.kristiansson@saunalahti.fi>
      Cc: Stafford Horne <shorne@gmail.com>
      Cc: Arnd Bergmann <arnd@arndb.de>
      Cc: openrisc@lists.librecores.org
      Acked-by: NStafford Horne <shorne@gmail.com>
      Signed-off-by: N"Eric W. Biederman" <ebiederm@xmission.com>
      500d5830
  5. 06 1月, 2018 1 次提交
  6. 04 1月, 2018 1 次提交
    • E
      signal: Simplify and fix kdb_send_sig · 0b44bf9a
      Eric W. Biederman 提交于
      - Rename from kdb_send_sig_info to kdb_send_sig
        As there is no meaningful siginfo sent
      
      - Use SEND_SIG_PRIV instead of generating a siginfo for a kdb
        signal.  The generated siginfo had a bogus rationale and was
        not correct in the face of pid namespaces.  SEND_SIG_PRIV
        is simpler and actually correct.
      
      - As the code grabs siglock just send the signal with siglock
        held instead of dropping siglock and attempting to grab it again.
      
      - Move the sig_valid test into kdb_kill where it can generate
        a good error message.
      Signed-off-by: NEric W. Biederman <ebiederm@xmission.com>
      0b44bf9a
  7. 01 1月, 2018 2 次提交
    • L
      Linux 4.15-rc6 · 30a7acd5
      Linus Torvalds 提交于
      30a7acd5
    • L
      Merge branch 'x86/urgent' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip · f39d7d78
      Linus Torvalds 提交于
      Pull x86 fixes from Thomas Gleixner:
       "A couple of fixlets for x86:
      
         - Fix the ESPFIX double fault handling for 5-level pagetables
      
         - Fix the commandline parsing for 'apic=' on 32bit systems and update
           documentation
      
         - Make zombie stack traces reliable
      
         - Fix kexec with stack canary
      
         - Fix the delivery mode for APICs which was missed when the x86
           vector management was converted to single target delivery. Caused a
           regression due to the broken hardware which ignores affinity
           settings in lowest prio delivery mode.
      
         - Unbreak modules when AMD memory encryption is enabled
      
         - Remove an unused parameter of prepare_switch_to"
      
      * 'x86/urgent' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
        x86/apic: Switch all APICs to Fixed delivery mode
        x86/apic: Update the 'apic=' description of setting APIC driver
        x86/apic: Avoid wrong warning when parsing 'apic=' in X86-32 case
        x86-32: Fix kexec with stack canary (CONFIG_CC_STACKPROTECTOR)
        x86: Remove unused parameter of prepare_switch_to
        x86/stacktrace: Make zombie stack traces reliable
        x86/mm: Unbreak modules that use the DMA API
        x86/build: Make isoimage work on Debian
        x86/espfix/64: Fix espfix double-fault handling on 5-level systems
      f39d7d78