summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2018-10-03signal: Remove the need for __ARCH_SI_PREABLE_SIZE and SI_PAD_SIZEEric W. Biederman
Rework the defintion of struct siginfo so that the array padding struct siginfo to SI_MAX_SIZE can be placed in a union along side of the rest of the struct siginfo members. The result is that we no longer need the __ARCH_SI_PREAMBLE_SIZE or SI_PAD_SIZE definitions. Signed-off-by: "Eric W. Biederman" <ebiederm@xmission.com>
2018-10-03signal: Fail sigqueueinfo if si_signo != sigEric W. Biederman
The kernel needs to validate that the contents of struct siginfo make sense as siginfo is copied into the kernel, so that the proper union members can be put in the appropriate locations. The field si_signo is a fundamental part of that validation. As such changing the contents of si_signo after the validation make no sense and can result in nonsense values in the kernel. As such simply fail if someone is silly enough to set si_signo out of sync with the signal number passed to sigqueueinfo. I don't expect a problem as glibc's sigqueue implementation sets "si_signo = sig" and CRIU just returns to the kernel what the kernel gave to it. If there is some application that calls sigqueueinfo directly that has a problem with this added sanity check we can revisit this when we see what kind of crazy that application is doing. Signed-off-by: "Eric W. Biederman" <ebiederm@xmission.com>
2018-10-03signal/sparc: Move EMT_TAGOVF into the generic siginfo.hEric W. Biederman
When moving all of the architectures specific si_codes into siginfo.h, I apparently overlooked EMT_TAGOVF. Move it now. Remove the now redundant test in siginfo_layout for SIGEMT as now NSIGEMT is always defined. Signed-off-by: "Eric W. Biederman" <ebiederm@xmission.com>
2018-09-27signal/unicore32: Use force_sig_fault where appropriateEric W. Biederman
Signed-off-by: "Eric W. Biederman" <ebiederm@xmission.com>
2018-09-27signal/unicore32: Generate siginfo in ucs32_notify_dieEric W. Biederman
Pass the signal number, and the signal code, and the faulting address into uc32_notify_die so the callers do not need to generate a struct siginfo. In ucs32_ntoify_die use the newly passed in information to call force_sig_fault to generate the siginfo and send the error. This simplifies the code making the chances of bugs much less likely. Signed-off-by: "Eric W. Biederman" <ebiederm@xmission.com>
2018-09-27signal/unicore32: Use send_sig_fault where appropriateEric W. Biederman
Signed-off-by: "Eric W. Biederman" <ebiederm@xmission.com>
2018-09-27signal/arc: Use force_sig_fault where appropriateEric W. Biederman
Acked-by: Vineet Gupta <vgupta@synopsys.com> Signed-off-by: "Eric W. Biederman" <ebiederm@xmission.com>
2018-09-27signal/arc: Push siginfo generation into unhandled_exceptionEric W. Biederman
Pass signr, sicode, and address into unhandled_exception as explicit parameters instead of members of struct siginfo. Then in unhandled exception generate and send the siginfo using force_sig_fault. This keeps the code simpler and less error prone. Acked-by: Vineet Gupta <vgupta@synopsys.com> Signed-off-by: "Eric W. Biederman" <ebiederm@xmission.com>
2018-09-27signal/ia64: Use force_sig_fault where appropriateEric W. Biederman
Acked-by: Tony Luck <tony.luck@intel.com> Signed-off-by: "Eric W. Biederman" <ebiederm@xmission.com>
2018-09-27signal/ia64: Use the force_sig(SIGSEGV,...) in ia64_rt_sigreturnEric W. Biederman
The ia64 handling of failure to return from a signal frame has been trying to set overlapping fields in struct siginfo since 2.3.43. The si_code corresponds to the fields that were stomped (not the field that is actually written), so I can not imagine a piece of userspace code making sense of the signal frame if it looks closely. In practice failure to return from a signal frame is a rare event that almost never happens. Someone using an alternate signal stack to recover and looking in detail is even more rare. So I presume no one has ever noticed and reported this ia64 nonsense. Sort this out by causing ia64 to use force_sig(SIGSEGV) like other architectures. Fixes: 2.3.43 Cc: Tony Luck <tony.luck@intel.com> Cc: Fenghua Yu <fenghua.yu@intel.com> Cc: linux-ia64@vger.kernel.org Acked-by: Tony Luck <tony.luck@intel.com> Signed-off-by: "Eric W. Biederman" <ebiederm@xmission.com>
2018-09-27signal/ia64: Use the generic force_sigsegv in setup_frameEric W. Biederman
The ia64 handling of failure to setup a signal frame has been trying to set overlapping fields in struct siginfo since 2.3.43. The si_pid and si_uid fields are stomped when the si_addr field is set. The si_code of SI_KERNEL indicates that si_pid and si_uid should be valid, and that si_addr does not exist. Being at odds with the definition of SI_KERNEL and with nothing to indicate that this was a signal frame setup failure there is no way for userspace to know that si_addr was filled out instead. In practice failure to setup a signal frame is rare, and si_pid and si_uid are always set to 0 when si_code is SI_KERNEL so I expect no one has looked closely enough before to see this weirdness. Further the only difference between force_sigsegv_info and the generic force_sigsegv other than the return code is that force_sigsegv_info stomps the si_uid and si_pid fields. Remove the bug and simplify the code by using force_sigsegv in this case just like other architectures. Fixes: 2.3.43 Cc: Tony Luck <tony.luck@intel.com> Cc: Fenghua Yu <fenghua.yu@intel.com> Cc: linux-ia64@vger.kernel.org Acked-by: Tony Luck <tony.luck@intel.com> Signed-off-by: "Eric W. Biederman" <ebiederm@xmission.com>
2018-09-27signal/arm/kvm: Use send_sig_mceerrEric W. Biederman
This simplifies the code making it clearer what is going on, and making the siginfo generation easier to maintain. Signed-off-by: "Eric W. Biederman" <ebiederm@xmission.com>
2018-09-27signal/arm: Use send_sig_fault where appropriateEric W. Biederman
Signed-off-by: "Eric W. Biederman" <ebiederm@xmission.com>
2018-09-27signal/arm: Use force_sig_fault where appropriateEric W. Biederman
Signed-off-by: "Eric W. Biederman" <ebiederm@xmission.com>
2018-09-27signal/arm: Push siginfo generation into arm_notify_dieEric W. Biederman
In arm_notify_die call force_sig_fault to let the generic code handle siginfo generation. This removes some boiler plate making the code easier to maintain in the long run. Signed-off-by: "Eric W. Biederman" <ebiederm@xmission.com>
2018-09-27signal/arm64: Use send_sig_fault where appropriateEric W. Biederman
Reviewed-by: Catalin Marinas <catalin.marinas@arm.com> Tested-by: Catalin Marinas <catalin.marinas@arm.com> Signed-off-by: "Eric W. Biederman" <ebiederm@xmission.com>
2018-09-27signal/arm64: Add and use arm64_force_sig_ptrace_errno_trapEric W. Biederman
Add arm64_force_sig_ptrace_errno_trap for consistency with arm64_force_sig_fault and use it where appropriate. This adds the show_signal logic to the force_sig_errno_trap case, where it was apparently overlooked earlier. Reviewed-by: Catalin Marinas <catalin.marinas@arm.com> Tested-by: Catalin Marinas <catalin.marinas@arm.com> Signed-off-by: "Eric W. Biederman" <ebiederm@xmission.com>
2018-09-27signal/arm64: In ptrace_hbptriggered name the signal description stringEric W. Biederman
This will let the description be reused shortly. Reviewed-by: Catalin Marinas <catalin.marinas@arm.com> Tested-by: Catalin Marinas <catalin.marinas@arm.com> Signed-off-by: "Eric W. Biederman" <ebiederm@xmission.com>
2018-09-27signal/arm64: Remove arm64_force_sig_infoEric W. Biederman
The function has no more callers so remove it. Reviewed-by: Catalin Marinas <catalin.marinas@arm.com> Tested-by: Catalin Marinas <catalin.marinas@arm.com> Signed-off-by: "Eric W. Biederman" <ebiederm@xmission.com>
2018-09-27signal/arm64: Add and use arm64_force_sig_mceerr as appropriateEric W. Biederman
Add arm64_force_sig_mceerr for consistency with arm64_force_sig_fault, and use it in the one location that can take advantage of it. This removes the fiddly filling out of siginfo before sending a signal reporting an memory error to userspace. Reviewed-by: Catalin Marinas <catalin.marinas@arm.com> Tested-by: Catalin Marinas <catalin.marinas@arm.com> Signed-off-by: "Eric W. Biederman" <ebiederm@xmission.com>
2018-09-27signal/arm64: Add and use arm64_force_sig_fault where appropriateEric W. Biederman
Wrap force_sig_fault with a helper that calls arm64_show_signal and call arm64_force_sig_fault where appropraite. Reviewed-by: Catalin Marinas <catalin.marinas@arm.com> Tested-by: Catalin Marinas <catalin.marinas@arm.com> Signed-off-by: Eric W. Biederman <ebiederm@xmission.com>
2018-09-27signal/arm64: Only call set_thread_esr once in do_page_faultEric W. Biederman
This code is truly common between the signal sending cases so share it. Reviewed-by: Catalin Marinas <catalin.marinas@arm.com> Tested-by: Catalin Marinas <catalin.marinas@arm.com> Signed-off-by: Eric W. Biederman <ebiederm@xmission.com>
2018-09-27signal/arm64: Only perform one esr_to_fault_info call in do_page_faultEric W. Biederman
As this work is truly common between all of the signal sending cases there is no need to repeat it between the different cases. Reviewed-by: Catalin Marinas <catalin.marinas@arm.com> Tested-by: Catalin Marinas <catalin.marinas@arm.com> Signed-off-by: Eric W. Biederman <ebiederm@xmission.com>
2018-09-27signal/arm64: Expand __do_user_fault and remove itEric W. Biederman
Not all of the signals passed to __do_user_fault can be handled the same way so expand the now tiny __do_user_fault in it's callers and remove it. Reviewed-by: Catalin Marinas <catalin.marinas@arm.com> Tested-by: Catalin Marinas <catalin.marinas@arm.com> Signed-off-by: "Eric W. Biederman" <ebiederm@xmission.com>
2018-09-27signal/arm64: For clarity separate the 3 signal sending cases in do_page_faultEric W. Biederman
It gets easy to confuse what is going on when some code is shared and some not so stop sharing the trivial bits of signal generation to make future updates easier to understand. Reviewed-by: Catalin Marinas <catalin.marinas@arm.com> Tested-by: Catalin Marinas <catalin.marinas@arm.com> Signed-off-by: "Eric W. Biederman" <ebiederm@xmission.com>
2018-09-27signal/arm64: Consolidate the two hwpoison cases in do_page_faultEric W. Biederman
These two cases are practically the same and use siginfo differently from the other signals sent from do_page_fault. So consolidate them to make future changes easier. Reviewed-by: Catalin Marinas <catalin.marinas@arm.com> Tested-by: Catalin Marinas <catalin.marinas@arm.com> Signed-off-by: "Eric W. Biederman" <ebiederm@xmission.com>
2018-09-27signal/arm64: Factor set_thread_esr out of __do_user_faultEric W. Biederman
This pepares for sending signals with something other than arm64_force_sig_info. Reviewed-by: Catalin Marinas <catalin.marinas@arm.com> Tested-by: Catalin Marinas <catalin.marinas@arm.com> Signed-off-by: "Eric W. Biederman" <ebiederm@xmission.com>
2018-09-27signal/arm64: Factor out arm64_show_signal from arm64_force_sig_infoEric W. Biederman
Filling in siginfo is error prone and so it is wise to use more specialized helpers to do that work. Factor out the arm specific unhandled signal reporting from the work of delivering a signal so the code can be modified to use functions that take the information to fill out siginfo as parameters. Reviewed-by: Catalin Marinas <catalin.marinas@arm.com> Tested-by: Catalin Marinas <catalin.marinas@arm.com> Signed-off-by: "Eric W. Biederman" <ebiederm@xmission.com>
2018-09-27signal/arm64: Remove unneeded tsk parameter from arm64_force_sig_infoEric W. Biederman
Every caller passes in current for tsk so there is no need to pass tsk. Instead make tsk a local variable initialized to current. Reviewed-by: Catalin Marinas <catalin.marinas@arm.com> Tested-by: Catalin Marinas <catalin.marinas@arm.com> Signed-off-by: "Eric W. Biederman" <ebiederm@xmission.com>
2018-09-27signal/arm64: Push siginfo generation into arm64_notify_dieEric W. Biederman
Instead of generating a struct siginfo before calling arm64_notify_die pass the signal number, tne sicode and the fault address into arm64_notify_die and have it call force_sig_fault instead of force_sig_info to let the generic code generate the struct siginfo. This keeps code passing just the needed information into siginfo generating code, making it easier to see what is happening and harder to get wrong. Further by letting the generic code handle the generation of struct siginfo it reduces the number of sites generating struct siginfo making it possible to review them and verify that all of the fiddly details for a structure passed to userspace are handled properly. Reviewed-by: Catalin Marinas <catalin.marinas@arm.com> Tested-by: Catalin Marinas <catalin.marinas@arm.com> Signed-off-by: "Eric W. Biederman" <ebiederm@xmission.com>
2018-09-21signal/powerpc: Use force_sig_fault where appropriateEric W. Biederman
Reviewed-by: Stephen Rothwell <sfr@canb.auug.org.au> Signed-off-by: "Eric W. Biederman" <ebiederm@xmission.com>
2018-09-21signal/powerpc: Simplify _exception_pkey by using force_sig_pkuerrEric W. Biederman
Call force_sig_pkuerr directly instead of rolling it by hand in _exception_pkey. Reviewed-by: Stephen Rothwell <sfr@canb.auug.org.au> Signed-off-by: "Eric W. Biederman" <ebiederm@xmission.com>
2018-09-21signal/powerpc: Specialize _exception_pkey for handling pkey exceptionsEric W. Biederman
Now that _exception no longer calls _exception_pkey it is no longer necessary to handle any signal with any si_code. All pkey exceptions are SIGSEGV with paired with SEGV_PKUERR. So just handle that case and remove the now unnecessary parameters from _exception_pkey. Reviewed-by: Stephen Rothwell <sfr@canb.auug.org.au> Signed-off-by: "Eric W. Biederman" <ebiederm@xmission.com>
2018-09-21signal/powerpc: Call force_sig_fault from _exceptionEric W. Biederman
The callers of _exception don't need the pkey exception logic because they are not processing a pkey exception. So just call exception_common directly and then call force_sig_fault to generate the appropriate siginfo and deliver the appropriate signal. Reviewed-by: Stephen Rothwell <sfr@canb.auug.org.au> Signed-off-by: "Eric W. Biederman" <ebiederm@xmission.com>
2018-09-21signal/powerpc: Factor the common exception code into exception_commonEric W. Biederman
It is brittle and wrong to populate si_pkey when there was not a pkey exception. The field does not exist for all si_codes and in some cases another field exists in the same memory location. So factor out the code that all exceptions handlers must run into exception_common, leaving the individual exception handlers to generate the signals themselves. Reviewed-by: Stephen Rothwell <sfr@canb.auug.org.au> Signed-off-by: "Eric W. Biederman" <ebiederm@xmission.com>
2018-09-21signal/powerpc: Remove pkey parameter from __bad_area_nosemaphoreEric W. Biederman
Now that bad_key_fault_exception no longer calls __bad_area_nosemaphore there is no reason for __bad_area_nosemaphore to handle pkeys. Reviewed-by: Stephen Rothwell <sfr@canb.auug.org.au> Signed-off-by: "Eric W. Biederman" <ebiederm@xmission.com>
2018-09-21signal/powerpc: Call _exception_pkey directly from bad_key_fault_exceptionEric W. Biederman
This removes the need for other code paths to deal with pkey exceptions. Reviewed-by: Stephen Rothwell <sfr@canb.auug.org.au> Signed-off-by: "Eric W. Biederman" <ebiederm@xmission.com>
2018-09-21signal/powerpc: Remove pkey parameter from __bad_areaEric W. Biederman
There are no callers of __bad_area that pass in a pkey parameter so it makes no sense to take one. Reviewed-by: Stephen Rothwell <sfr@canb.auug.org.au> Signed-off-by: "Eric W. Biederman" <ebiederm@xmission.com>
2018-09-21signal/powerpc: Use force_sig_mceerr as appropriateEric W. Biederman
In do_sigbus isolate the mceerr signaling code and call force_sig_mceerr instead of falling through to the force_sig_info that works for all of the other signals. Reviewed-by: Stephen Rothwell <sfr@canb.auug.org.au> Signed-off-by: "Eric W. Biederman" <ebiederm@xmission.com>
2018-09-21signal/x86: Use force_sig_fault where appropriateEric W. Biederman
Reviewed-by: Thomas Gleixner <tglx@linutronix.de> Signed-off-by: "Eric W. Biederman" <ebiederm@xmission.com>
2018-09-21signal/x86: Pass pkey by valueEric W. Biederman
Now that si_code == SEGV_PKUERR is the flag indicating that a pkey is present there is no longer a need to pass a pointer to a local pkey value, instead pkey can be passed more efficiently by value. Reviewed-by: Thomas Gleixner <tglx@linutronix.de> Signed-off-by: "Eric W. Biederman" <ebiederm@xmission.com>
2018-09-21signal/x86: Replace force_sig_info_fault with force_sig_faultEric W. Biederman
Now that the pkey handling has been removed force_sig_info_fault and force_sig_fault perform identical work. Just the type of the address paramter is different. So replace calls to force_sig_info_fault with calls to force_sig_fault, and remove force_sig_info_fault. Reviewed-by: Thomas Gleixner <tglx@linutronix.de> Signed-off-by: "Eric W. Biederman" <ebiederm@xmission.com>
2018-09-21signal/x86: Call force_sig_pkuerr from __bad_area_nosemaphoreEric W. Biederman
There is only one code path that can generate a pkuerr signal. That code path calls __bad_area_nosemaphore and can be dectected by testing if si_code == SEGV_PKUERR. It can be seen from inspection that all of the other tests in fill_sig_info_pkey are unnecessary. Therefore call force_sig_pkuerr directly from __bad_area_semaphore and remove fill_sig_info_pkey. At the same time move the comment above force_sig_info_pkey into bad_area_access_error, so that the documentation about pkey generation races is not lost. Reviewed-by: Thomas Gleixner <tglx@linutronix.de> Signed-off-by: "Eric W. Biederman" <ebiederm@xmission.com>
2018-09-21signal/x86: Pass pkey not vma into __bad_areaEric W. Biederman
There is only one caller of __bad_area that passes in PKUERR and thus will generate a siginfo with si_pkey set. Therefore simplify the logic and hoist reading of vma_pkey up into that caller, and just pass *pkey into __bad_area. Reviewed-by: Thomas Gleixner <tglx@linutronix.de> Signed-off-by: "Eric W. Biederman" <ebiederm@xmission.com>
2018-09-21signal/x86: Don't compute pkey in __do_page_faultEric W. Biederman
There are no more users of the computed pkey value in __do_page_fault so stop computing the value. Reviewed-by: Thomas Gleixner <tglx@linutronix.de> Signed-off-by: "Eric W. Biederman" <ebiederm@xmission.com>
2018-09-21signal/x86: Remove pkey parameter from mm_fault_errorEric W. Biederman
After the previous cleanups to do_sigbus and and bad_area_nosemaphore mm_fault_error no now longer uses it's pkey parameter. Therefore remove the unused parameter. Reviewed-by: Thomas Gleixner <tglx@linutronix.de> Signed-off-by: "Eric W. Biederman" <ebiederm@xmission.com>
2018-09-21signal/x86: Remove the pkey parameter from do_sigbusEric W. Biederman
The function do_sigbus never sets si_code to PKUERR so it can never return a pkey to userspace. Therefore remove the unusable pkey parameter from do_sigbus. Reviewed-by: Thomas Gleixner <tglx@linutronix.de> Signed-off-by: "Eric W. Biederman" <ebiederm@xmission.com>
2018-09-21signal/x86: Remove pkey parameter from bad_area_nosemaphoreEric W. Biederman
The function bad_area_nosemaphore always sets si_code to SEGV_MAPERR and as such can never return a pkey parameter. Therefore remove the unusable pkey parameter from bad_area_nosemaphore. Reviewed-by: Thomas Gleixner <tglx@linutronix.de> Signed-off-by: "Eric W. Biederman" <ebiederm@xmission.com>
2018-09-21signal/x86/traps: Simplify trap generationEric W. Biederman
Update the DO_ERROR macro to take si_code and si_addr values for a siginfo, removing the need for the fill_trap_info function. Update do_trap to also take the sicode and si_addr values for a sigininfo and modify the code to call force_sig when a sicode is not passed in and to call force_sig_fault when all of the information is present. Making this a more obvious, simpler and less error prone construction. Reviewed-by: Thomas Gleixner <tglx@linutronix.de> Signed-off-by: "Eric W. Biederman" <ebiederm@xmission.com>
2018-09-21signal/x86/traps: Use force_sig instead of open coding it.Eric W. Biederman
The function "force_sig(sig, tsk)" is equivalent to " force_sig_info(sig, SEND_SIG_PRIV, tsk)". Using the siginfo variants can be error prone so use the simpler old fashioned force_sig variant, and with luck the force_sig_info variant can go away. Reviewed-by: Thomas Gleixner <tglx@linutronix.de> Signed-off-by: "Eric W. Biederman" <ebiederm@xmission.com>