| Message ID | 1517338243-9749-4-git-send-email-Dave.Martin@arm.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
Hi Dave, On 30/01/18 18:50, Dave Martin wrote: > Currently, as reported by Eric, an invalid si_code value 0 is > passed in many signals delivered to userspace in response to faults > and other kernel errors. Typically 0 is passed when the fault is > insufficiently diagnosable or when there does not appear to be any > sensible alternative value to choose. > > This appears to violate POSIX, and is intuitively wrong for at > least two reasons arising from the fact that 0 == SI_USER: > > 1) si_code is a union selector, and SI_USER (and si_code <= 0 in > general) implies the existence of a different set of fields > (siginfo._kill) from that which exists for a fault signal > (siginfo._sigfault). However, the code raising the signal > typically writes only the _sigfault fields, and the _kill > fields make no sense in this case. > > Thus when userspace sees si_code == 0 (SI_USER) it may > legitimately inspect fields in the inactive union member _kill > and obtain garbage as a result. > > There appears to be software in the wild relying on this, > albeit generally only for printing diagnostic messages. > > 2) Software that wants to be robust against spurious signals may > discard signals where si_code == SI_USER (or <= 0), or may > filter such signals based on the si_uid and si_pid fields of > siginfo._sigkill. In the case of fault signals, this means > that important (and usually fatal) error conditions may be > silently ignored. > > In practice, many of the faults for which arm64 passes si_code == 0 > are undiagnosable conditions such as exceptions with syndrome > values in ESR_ELx to which the architecture does not yet assign any > meaning, or conditions indicative of a bug or error in the kernel > or system and thus that are unrecoverable and should never occur in > normal operation. > > The approach taken in this patch is to translate all such > undiagnosable or "impossible" synchronous fault conditions to > SIGKILL, since these are at least probably localisable to a single > process. Some of these conditions should really result in a kernel > panic, but due to the lack of diagnostic information it is > difficult to be certain: this patch does not add any calls to > panic(), but this could change later if justified. > > Although si_code will not reach userspace in the case of SIGKILL, > it is still desirable to pass a nonzero value so that the common > siginfo handling code can detect incorrect use of si_code == 0 > without false positives. In this case the si_code dependent > siginfo fields will not be correctly initialised, but since they > are not passed to userspace I deem this not to matter. > > A few faults can reasonably occur in realistic userspace scenarios, > and _should_ raise a regular, handleable (but perhaps not > ignorable/blockable) signal: for these, this patch attempts to > choose a suitable standard si_code value for the raised signal in > each case instead of 0. > diff --git a/arch/arm64/mm/fault.c b/arch/arm64/mm/fault.c > index 9b7f89d..4baa922 100644 > --- a/arch/arm64/mm/fault.c > +++ b/arch/arm64/mm/fault.c > @@ -607,70 +607,70 @@ static int do_sea(unsigned long addr, unsigned int esr, struct pt_regs *regs) [..] > + { do_sea, SIGKILL, SI_KERNEL, "level 0 (translation table walk)" }, > + { do_sea, SIGKILL, SI_KERNEL, "level 1 (translation table walk)" }, > + { do_sea, SIGKILL, SI_KERNEL, "level 2 (translation table walk)" }, > + { do_sea, SIGKILL, SI_KERNEL, "level 3 (translation table walk)" }, > + { do_sea, SIGBUS, BUS_OBJERR, "synchronous parity or ECC error" }, // Reserved when RAS is implemented I agree the translation-table related external-aborts should end up with SIGKILL: there is nothing user-space can do. You use the fault_info table to vary the signal and si_code that should be used, but do_mem_abort() only uses these if the fn returns an error. For do_sea(), regardless of the values in this table SIGBUS will be generated as it always returns 0. > @@ -596,7 +596,7 @@ static int do_sea(unsigned long addr, unsigned int esr, struct pt_regs *regs) > > info.si_signo = SIGBUS; > info.si_errno = 0; > - info.si_code = 0; > + info.si_code = BUS_OBJERR; > if (esr & ESR_ELx_FnV) > info.si_addr = NULL; > else do_sea() has the right fault_info entry to hand, so I think these need to change to inf->sig and inf->code. (I assume its not valid to set si_addr for SIGKILL...) Thanks, James
On Tue, Feb 13, 2018 at 01:58:55PM +0000, James Morse wrote: > Hi Dave, > > On 30/01/18 18:50, Dave Martin wrote: [...] > > The approach taken in this patch is to translate all such > > undiagnosable or "impossible" synchronous fault conditions to > > SIGKILL, since these are at least probably localisable to a single > > process. Some of these conditions should really result in a kernel > > panic, but due to the lack of diagnostic information it is > > difficult to be certain: this patch does not add any calls to > > panic(), but this could change later if justified. > > > > Although si_code will not reach userspace in the case of SIGKILL, > > it is still desirable to pass a nonzero value so that the common > > siginfo handling code can detect incorrect use of si_code == 0 > > without false positives. In this case the si_code dependent > > siginfo fields will not be correctly initialised, but since they > > are not passed to userspace I deem this not to matter. > > > > A few faults can reasonably occur in realistic userspace scenarios, > > and _should_ raise a regular, handleable (but perhaps not > > ignorable/blockable) signal: for these, this patch attempts to > > choose a suitable standard si_code value for the raised signal in > > each case instead of 0. > > > > diff --git a/arch/arm64/mm/fault.c b/arch/arm64/mm/fault.c > > index 9b7f89d..4baa922 100644 > > --- a/arch/arm64/mm/fault.c > > +++ b/arch/arm64/mm/fault.c > > @@ -607,70 +607,70 @@ static int do_sea(unsigned long addr, unsigned int esr, struct pt_regs *regs) > [..] > > + { do_sea, SIGKILL, SI_KERNEL, "level 0 (translation table walk)" }, > > + { do_sea, SIGKILL, SI_KERNEL, "level 1 (translation table walk)" }, > > + { do_sea, SIGKILL, SI_KERNEL, "level 2 (translation table walk)" }, > > + { do_sea, SIGKILL, SI_KERNEL, "level 3 (translation table walk)" }, > > + { do_sea, SIGBUS, BUS_OBJERR, "synchronous parity or ECC error" }, // Reserved when RAS is implemented > > I agree the translation-table related external-aborts should end up with > SIGKILL: there is nothing user-space can do. > > You use the fault_info table to vary the signal and si_code that should be used, > but do_mem_abort() only uses these if the fn returns an error. For do_sea(), > regardless of the values in this table SIGBUS will be generated as it always > returns 0. > > > > @@ -596,7 +596,7 @@ static int do_sea(unsigned long addr, unsigned int esr, > struct pt_regs *regs) > > > > info.si_signo = SIGBUS; > > info.si_errno = 0; > > - info.si_code = 0; > > + info.si_code = BUS_OBJERR; > > if (esr & ESR_ELx_FnV) > > info.si_addr = NULL; > > else > > do_sea() has the right fault_info entry to hand, so I think these need to change > to inf->sig and inf->code. (I assume its not valid to set si_addr for SIGKILL...) Yes, I guess that makes sense. For SIGKILL, I'm assuming that it is harmless to populate si_addr: even though not strictly valid, the signal is never delivered to userspace. Even ptrace cannot see SIGKILL -- the trace just disappears and further ptrace calls fail with ESRCH. If is matters, I guess we could prepopulate si_uid = si_pid = 0 for this case. That's at least cleaner, so I might do that. For do_sea: I was thinking of the fault_info[] table entries as for the fallback case only, but (a) I also try to use them to affect what do_sea() does (which, as you observe, doesn't work right now), and (b) there's no reason why they shouldn't inform what fn does. So I think you're right. However, rather than duplicate code I wonder whether we can just rearrange do_mem_abort() so that the lines info.si_signo = inf->sig; info.si_errno = 0; info.si_code = inf->code; info.si_addr = (void __user *)addr; are moved ahead of the call to inf->fn(). This would have the effect of pre-populating info with sane defaults while still allowing inf->fn() to override them if appropriate. Thoughts? Cheers ---Dave
Hi Dave, On 13/02/18 15:22, Dave Martin wrote: > On Tue, Feb 13, 2018 at 01:58:55PM +0000, James Morse wrote: >> On 30/01/18 18:50, Dave Martin wrote: >>> diff --git a/arch/arm64/mm/fault.c b/arch/arm64/mm/fault.c >>> index 9b7f89d..4baa922 100644 >>> --- a/arch/arm64/mm/fault.c >>> +++ b/arch/arm64/mm/fault.c >>> @@ -607,70 +607,70 @@ static int do_sea(unsigned long addr, unsigned int esr, struct pt_regs *regs) >> [..] >>> + { do_sea, SIGKILL, SI_KERNEL, "level 0 (translation table walk)" }, >>> + { do_sea, SIGKILL, SI_KERNEL, "level 1 (translation table walk)" }, >>> + { do_sea, SIGKILL, SI_KERNEL, "level 2 (translation table walk)" }, >>> + { do_sea, SIGKILL, SI_KERNEL, "level 3 (translation table walk)" }, >>> + { do_sea, SIGBUS, BUS_OBJERR, "synchronous parity or ECC error" }, // Reserved when RAS is implemented >> >> I agree the translation-table related external-aborts should end up with >> SIGKILL: there is nothing user-space can do. >> >> You use the fault_info table to vary the signal and si_code that should be used, >> but do_mem_abort() only uses these if the fn returns an error. For do_sea(), >> regardless of the values in this table SIGBUS will be generated as it always >> returns 0. >> >> >>> @@ -596,7 +596,7 @@ static int do_sea(unsigned long addr, unsigned int esr, >> struct pt_regs *regs) >>> >>> info.si_signo = SIGBUS; >>> info.si_errno = 0; >>> - info.si_code = 0; >>> + info.si_code = BUS_OBJERR; >>> if (esr & ESR_ELx_FnV) >>> info.si_addr = NULL; >>> else >> >> do_sea() has the right fault_info entry to hand, so I think these need to change >> to inf->sig and inf->code. (I assume its not valid to set si_addr for SIGKILL...) > > Yes, I guess that makes sense. > > For SIGKILL, I'm assuming that it is harmless to populate si_addr: even > though not strictly valid, the signal is never delivered to userspace. > Even ptrace cannot see SIGKILL -- the trace just disappears and further > ptrace calls fail with ESRCH. Good point! > If is matters, I guess we could prepopulate si_uid = si_pid = 0 for > this case. That's at least cleaner, so I might do that. > > > For do_sea: > > I was thinking of the fault_info[] table entries as for the fallback > case only, but (a) I also try to use them to affect what do_sea() does > (which, as you observe, doesn't work right now), and (b) there's no > reason why they shouldn't inform what fn does. Sure, > However, rather than duplicate code I wonder whether we can just > rearrange do_mem_abort() so that the lines > > info.si_signo = inf->sig; > info.si_errno = 0; > info.si_code = inf->code; > info.si_addr = (void __user *)addr; > > are moved ahead of the call to inf->fn(). > > This would have the effect of pre-populating info with sane defaults > while still allowing inf->fn() to override them if appropriate. I like the idea. It's a bit strange that do_mem_abort() looks up the table entry to call the handler, which looks up the table entry to find out what it should do. (__do_user_fault() already does this). This would change all of 'fn's prototypes, to save the struct-siginfo duplication in do_sea() and __do_user_fault(). Should the 'leaf' helpers still send the signal, or update the siginfo and return back to do_mem_abort()? Getting things like do_alignment_fault() in a kernel stack trace is the only reason I can see... Thanks, James
diff --git a/arch/arm64/kernel/fpsimd.c b/arch/arm64/kernel/fpsimd.c index 4fecda1..944f24b 100644 --- a/arch/arm64/kernel/fpsimd.c +++ b/arch/arm64/kernel/fpsimd.c @@ -286,8 +286,8 @@ static void task_fpsimd_save(void) * re-enter user with corrupt state. * There's no way to recover, so kill it: */ - force_signal_inject( - SIGKILL, 0, current_pt_regs(), 0); + force_signal_inject(SIGKILL, SI_KERNEL, + current_pt_regs(), 0); return; } diff --git a/arch/arm64/mm/fault.c b/arch/arm64/mm/fault.c index 9b7f89d..4baa922 100644 --- a/arch/arm64/mm/fault.c +++ b/arch/arm64/mm/fault.c @@ -596,7 +596,7 @@ static int do_sea(unsigned long addr, unsigned int esr, struct pt_regs *regs) info.si_signo = SIGBUS; info.si_errno = 0; - info.si_code = 0; + info.si_code = BUS_OBJERR; if (esr & ESR_ELx_FnV) info.si_addr = NULL; else @@ -607,70 +607,70 @@ static int do_sea(unsigned long addr, unsigned int esr, struct pt_regs *regs) } static const struct fault_info fault_info[] = { - { do_bad, SIGBUS, 0, "ttbr address size fault" }, - { do_bad, SIGBUS, 0, "level 1 address size fault" }, - { do_bad, SIGBUS, 0, "level 2 address size fault" }, - { do_bad, SIGBUS, 0, "level 3 address size fault" }, + { do_bad, SIGKILL, SI_KERNEL, "ttbr address size fault" }, + { do_bad, SIGKILL, SI_KERNEL, "level 1 address size fault" }, + { do_bad, SIGKILL, SI_KERNEL, "level 2 address size fault" }, + { do_bad, SIGKILL, SI_KERNEL, "level 3 address size fault" }, { do_translation_fault, SIGSEGV, SEGV_MAPERR, "level 0 translation fault" }, { do_translation_fault, SIGSEGV, SEGV_MAPERR, "level 1 translation fault" }, { do_translation_fault, SIGSEGV, SEGV_MAPERR, "level 2 translation fault" }, { do_translation_fault, SIGSEGV, SEGV_MAPERR, "level 3 translation fault" }, - { do_bad, SIGBUS, 0, "unknown 8" }, + { do_bad, SIGKILL, SI_KERNEL, "unknown 8" }, { do_page_fault, SIGSEGV, SEGV_ACCERR, "level 1 access flag fault" }, { do_page_fault, SIGSEGV, SEGV_ACCERR, "level 2 access flag fault" }, { do_page_fault, SIGSEGV, SEGV_ACCERR, "level 3 access flag fault" }, - { do_bad, SIGBUS, 0, "unknown 12" }, + { do_bad, SIGKILL, SI_KERNEL, "unknown 12" }, { do_page_fault, SIGSEGV, SEGV_ACCERR, "level 1 permission fault" }, { do_page_fault, SIGSEGV, SEGV_ACCERR, "level 2 permission fault" }, { do_page_fault, SIGSEGV, SEGV_ACCERR, "level 3 permission fault" }, - { do_sea, SIGBUS, 0, "synchronous external abort" }, - { do_bad, SIGBUS, 0, "unknown 17" }, - { do_bad, SIGBUS, 0, "unknown 18" }, - { do_bad, SIGBUS, 0, "unknown 19" }, - { do_sea, SIGBUS, 0, "level 0 (translation table walk)" }, - { do_sea, SIGBUS, 0, "level 1 (translation table walk)" }, - { do_sea, SIGBUS, 0, "level 2 (translation table walk)" }, - { do_sea, SIGBUS, 0, "level 3 (translation table walk)" }, - { do_sea, SIGBUS, 0, "synchronous parity or ECC error" }, // Reserved when RAS is implemented - { do_bad, SIGBUS, 0, "unknown 25" }, - { do_bad, SIGBUS, 0, "unknown 26" }, - { do_bad, SIGBUS, 0, "unknown 27" }, - { do_sea, SIGBUS, 0, "level 0 synchronous parity error (translation table walk)" }, // Reserved when RAS is implemented - { do_sea, SIGBUS, 0, "level 1 synchronous parity error (translation table walk)" }, // Reserved when RAS is implemented - { do_sea, SIGBUS, 0, "level 2 synchronous parity error (translation table walk)" }, // Reserved when RAS is implemented - { do_sea, SIGBUS, 0, "level 3 synchronous parity error (translation table walk)" }, // Reserved when RAS is implemented - { do_bad, SIGBUS, 0, "unknown 32" }, + { do_sea, SIGBUS, BUS_OBJERR, "synchronous external abort" }, + { do_bad, SIGKILL, SI_KERNEL, "unknown 17" }, + { do_bad, SIGKILL, SI_KERNEL, "unknown 18" }, + { do_bad, SIGKILL, SI_KERNEL, "unknown 19" }, + { do_sea, SIGKILL, SI_KERNEL, "level 0 (translation table walk)" }, + { do_sea, SIGKILL, SI_KERNEL, "level 1 (translation table walk)" }, + { do_sea, SIGKILL, SI_KERNEL, "level 2 (translation table walk)" }, + { do_sea, SIGKILL, SI_KERNEL, "level 3 (translation table walk)" }, + { do_sea, SIGBUS, BUS_OBJERR, "synchronous parity or ECC error" }, // Reserved when RAS is implemented + { do_bad, SIGKILL, SI_KERNEL, "unknown 25" }, + { do_bad, SIGKILL, SI_KERNEL, "unknown 26" }, + { do_bad, SIGKILL, SI_KERNEL, "unknown 27" }, + { do_sea, SIGKILL, SI_KERNEL, "level 0 synchronous parity error (translation table walk)" }, // Reserved when RAS is implemented + { do_sea, SIGKILL, SI_KERNEL, "level 1 synchronous parity error (translation table walk)" }, // Reserved when RAS is implemented + { do_sea, SIGKILL, SI_KERNEL, "level 2 synchronous parity error (translation table walk)" }, // Reserved when RAS is implemented + { do_sea, SIGKILL, SI_KERNEL, "level 3 synchronous parity error (translation table walk)" }, // Reserved when RAS is implemented + { do_bad, SIGKILL, SI_KERNEL, "unknown 32" }, { do_alignment_fault, SIGBUS, BUS_ADRALN, "alignment fault" }, - { do_bad, SIGBUS, 0, "unknown 34" }, - { do_bad, SIGBUS, 0, "unknown 35" }, - { do_bad, SIGBUS, 0, "unknown 36" }, - { do_bad, SIGBUS, 0, "unknown 37" }, - { do_bad, SIGBUS, 0, "unknown 38" }, - { do_bad, SIGBUS, 0, "unknown 39" }, - { do_bad, SIGBUS, 0, "unknown 40" }, - { do_bad, SIGBUS, 0, "unknown 41" }, - { do_bad, SIGBUS, 0, "unknown 42" }, - { do_bad, SIGBUS, 0, "unknown 43" }, - { do_bad, SIGBUS, 0, "unknown 44" }, - { do_bad, SIGBUS, 0, "unknown 45" }, - { do_bad, SIGBUS, 0, "unknown 46" }, - { do_bad, SIGBUS, 0, "unknown 47" }, - { do_bad, SIGBUS, 0, "TLB conflict abort" }, - { do_bad, SIGBUS, 0, "Unsupported atomic hardware update fault" }, - { do_bad, SIGBUS, 0, "unknown 50" }, - { do_bad, SIGBUS, 0, "unknown 51" }, - { do_bad, SIGBUS, 0, "implementation fault (lockdown abort)" }, - { do_bad, SIGBUS, 0, "implementation fault (unsupported exclusive)" }, - { do_bad, SIGBUS, 0, "unknown 54" }, - { do_bad, SIGBUS, 0, "unknown 55" }, - { do_bad, SIGBUS, 0, "unknown 56" }, - { do_bad, SIGBUS, 0, "unknown 57" }, - { do_bad, SIGBUS, 0, "unknown 58" }, - { do_bad, SIGBUS, 0, "unknown 59" }, - { do_bad, SIGBUS, 0, "unknown 60" }, - { do_bad, SIGBUS, 0, "section domain fault" }, - { do_bad, SIGBUS, 0, "page domain fault" }, - { do_bad, SIGBUS, 0, "unknown 63" }, + { do_bad, SIGKILL, SI_KERNEL, "unknown 34" }, + { do_bad, SIGKILL, SI_KERNEL, "unknown 35" }, + { do_bad, SIGKILL, SI_KERNEL, "unknown 36" }, + { do_bad, SIGKILL, SI_KERNEL, "unknown 37" }, + { do_bad, SIGKILL, SI_KERNEL, "unknown 38" }, + { do_bad, SIGKILL, SI_KERNEL, "unknown 39" }, + { do_bad, SIGKILL, SI_KERNEL, "unknown 40" }, + { do_bad, SIGKILL, SI_KERNEL, "unknown 41" }, + { do_bad, SIGKILL, SI_KERNEL, "unknown 42" }, + { do_bad, SIGKILL, SI_KERNEL, "unknown 43" }, + { do_bad, SIGKILL, SI_KERNEL, "unknown 44" }, + { do_bad, SIGKILL, SI_KERNEL, "unknown 45" }, + { do_bad, SIGKILL, SI_KERNEL, "unknown 46" }, + { do_bad, SIGKILL, SI_KERNEL, "unknown 47" }, + { do_bad, SIGKILL, SI_KERNEL, "TLB conflict abort" }, + { do_bad, SIGKILL, SI_KERNEL, "Unsupported atomic hardware update fault" }, + { do_bad, SIGKILL, SI_KERNEL, "unknown 50" }, + { do_bad, SIGKILL, SI_KERNEL, "unknown 51" }, + { do_bad, SIGKILL, SI_KERNEL, "implementation fault (lockdown abort)" }, + { do_bad, SIGBUS, BUS_OBJERR, "implementation fault (unsupported exclusive)" }, + { do_bad, SIGKILL, SI_KERNEL, "unknown 54" }, + { do_bad, SIGKILL, SI_KERNEL, "unknown 55" }, + { do_bad, SIGKILL, SI_KERNEL, "unknown 56" }, + { do_bad, SIGKILL, SI_KERNEL, "unknown 57" }, + { do_bad, SIGKILL, SI_KERNEL, "unknown 58" }, + { do_bad, SIGKILL, SI_KERNEL, "unknown 59" }, + { do_bad, SIGKILL, SI_KERNEL, "unknown 60" }, + { do_bad, SIGKILL, SI_KERNEL, "section domain fault" }, + { do_bad, SIGKILL, SI_KERNEL, "page domain fault" }, + { do_bad, SIGKILL, SI_KERNEL, "unknown 63" }, }; int handle_guest_sea(phys_addr_t addr, unsigned int esr) @@ -739,11 +739,11 @@ static struct fault_info __refdata debug_fault_info[] = { { do_bad, SIGTRAP, TRAP_HWBKPT, "hardware breakpoint" }, { do_bad, SIGTRAP, TRAP_HWBKPT, "hardware single-step" }, { do_bad, SIGTRAP, TRAP_HWBKPT, "hardware watchpoint" }, - { do_bad, SIGBUS, 0, "unknown 3" }, + { do_bad, SIGKILL, SI_KERNEL, "unknown 3" }, { do_bad, SIGTRAP, TRAP_BRKPT, "aarch32 BKPT" }, - { do_bad, SIGTRAP, 0, "aarch32 vector catch" }, + { do_bad, SIGKILL, SI_KERNEL, "aarch32 vector catch" }, { early_brk64, SIGTRAP, TRAP_BRKPT, "aarch64 BRK" }, - { do_bad, SIGBUS, 0, "unknown 7" }, + { do_bad, SIGKILL, SI_KERNEL, "unknown 7" }, }; void __init hook_debug_fault_code(int nr,
Currently, as reported by Eric, an invalid si_code value 0 is passed in many signals delivered to userspace in response to faults and other kernel errors. Typically 0 is passed when the fault is insufficiently diagnosable or when there does not appear to be any sensible alternative value to choose. This appears to violate POSIX, and is intuitively wrong for at least two reasons arising from the fact that 0 == SI_USER: 1) si_code is a union selector, and SI_USER (and si_code <= 0 in general) implies the existence of a different set of fields (siginfo._kill) from that which exists for a fault signal (siginfo._sigfault). However, the code raising the signal typically writes only the _sigfault fields, and the _kill fields make no sense in this case. Thus when userspace sees si_code == 0 (SI_USER) it may legitimately inspect fields in the inactive union member _kill and obtain garbage as a result. There appears to be software in the wild relying on this, albeit generally only for printing diagnostic messages. 2) Software that wants to be robust against spurious signals may discard signals where si_code == SI_USER (or <= 0), or may filter such signals based on the si_uid and si_pid fields of siginfo._sigkill. In the case of fault signals, this means that important (and usually fatal) error conditions may be silently ignored. In practice, many of the faults for which arm64 passes si_code == 0 are undiagnosable conditions such as exceptions with syndrome values in ESR_ELx to which the architecture does not yet assign any meaning, or conditions indicative of a bug or error in the kernel or system and thus that are unrecoverable and should never occur in normal operation. The approach taken in this patch is to translate all such undiagnosable or "impossible" synchronous fault conditions to SIGKILL, since these are at least probably localisable to a single process. Some of these conditions should really result in a kernel panic, but due to the lack of diagnostic information it is difficult to be certain: this patch does not add any calls to panic(), but this could change later if justified. Although si_code will not reach userspace in the case of SIGKILL, it is still desirable to pass a nonzero value so that the common siginfo handling code can detect incorrect use of si_code == 0 without false positives. In this case the si_code dependent siginfo fields will not be correctly initialised, but since they are not passed to userspace I deem this not to matter. A few faults can reasonably occur in realistic userspace scenarios, and _should_ raise a regular, handleable (but perhaps not ignorable/blockable) signal: for these, this patch attempts to choose a suitable standard si_code value for the raised signal in each case instead of 0. Reported-by: Eric W. Biederman <ebiederm@xmission.com> Signed-off-by: Dave Martin <Dave.Martin@arm.com> --- arch/arm64/kernel/fpsimd.c | 4 +- arch/arm64/mm/fault.c | 114 ++++++++++++++++++++++----------------------- 2 files changed, 59 insertions(+), 59 deletions(-)