[RFC PATCH 0/2] arm64: Fix invalid si_codes for fault signals

[RFC PATCH 0/2] arm64: Fix invalid si_codes for fault signals

[Dave Martin]

As reported by Eric Biederman, [1], [2], [3] etc., several architectures
are inappropriately setting si_code to 0 when signaling faults to
userspace, which will interpret this value as SI_USER leading to garbage
being read out of siginfo fields that the kernel doesn't initialise.

This seems not to be a huge problem in practice, since many affected
faults should only happen if the kernel or hardware is buggy or broken.
However, there are some cases that don't fall under this.

This RFC series proposes fixes to eliminate these si_code == 0 cases
from arm64.  Some of the changes may be controversial.

There are two main headlines here, which may be applicable to other
architectures:

 * addition of a new code FPE_UNKNOWN for undiagnosable floating-point
   exception traps;

 * delivering SIGKILL instead of SIGSEGV/BUS/TRAP etc. for "impossible"
   exceptions that are not feasible to recover from and likely indicate
   a kernel or system bug or failure.

In particular there is likely to be a fair amount of overlap between arm
and arm64 here, but due to the longer history and evolution of the arm
tree and 32-bit architecture I'm less confident in making correct
judgements for that case.  This series doesn't touch arm, for now.

This series has been build-tested only.

[1] [PATCH 00/11] siginfo fixes/cleanups esp SI_USER
https://marc.info/?l=linux-kernel&m=151571871109016&w=2

[2] [PATCH 08/11] signal/arm: Document conflicts with SI_USER and SIGFPE
http://lists.infradead.org/pipermail/linux-arm-kernel/2018-January/553574.html

[3] [PATCH 07/11] signal/arm64: Document conflicts with SI_USER and SIGFPE, SIGTRAP, SIGBUS
lists.infradead.org/pipermail/linux-arm-kernel/2018-January/553573.html

Dave Martin (2):
  arm64: fpsimd: Fix bad si_code for undiagnosed SIGFPE
  arm64: signal: Ensure si_code is valid for all fault signals

 arch/arm64/include/asm/esr.h       |   9 +++
 arch/arm64/kernel/fpsimd.c         |  31 +++++-----
 arch/arm64/mm/fault.c              | 114 ++++++++++++++++++-------------------
 include/uapi/asm-generic/siginfo.h |   3 +-
 4 files changed, 85 insertions(+), 72 deletions(-)

-- 
2.1.4

[RFC PATCH 1/2] arm64: fpsimd: Fix bad si_code for undiagnosed SIGFPE

[Dave Martin]

Currently a SIGFPE delivered in response to a floating-point
exception trap may have si_code set to 0 on arm64.  As reported by
Eric, this is a bad idea since this is the value of SI_USER -- yet
this signal is definitely not the result of kill(2), tgkill(2) etc.
and si_uid and si_pid make limited sense whereas we do want to
yield a value for si_addr (which doesn't exist for SI_USER).

It's not entirely clear whether the architecure permits a
"spurious" fp exception trap where none of the exception flag bits
in ESR_ELx is set.  (IMHO the architectural intent is to forbid
this.)  However, it does permit those bits to contain garbage if
the TFV bit in ESR_ELx is 0.  That case isn't currently handled at
all and may result in si_code == 0 or si_code containing a FPE_FLT*
constant corresponding to an exception that did not in fact happen.

There is nothing sensible we can return for si_code in such cases,
but SI_USER is certainly not appropriate and will lead to violation
of legitimate userspace assumptions.

This patch allocates a new si_code value FPE_UNKNOWN that at least
does not conflict with any existing SI_* or FPE_* code, and yields
this in si_code for undiagnosable cases.  This is probably the best
simplicity/incorrectness tradeoff achieveable without relying on
implementation-dependent features or adding a lot of code.  In any
case, there appears to be no perfect solution possible that would
justify a lot of effort here.

Yielding FPE_UNKNOWN when some well-defined fp exception caused the
trap is a violation of POSIX, but this is forced by the
architecture.  We have no realistic prospect of yielding the
correct code in such cases.  At present I am not aware of any ARMv8
implementation that supports trapped floating-point exceptions in
any case.

The new code may be applicable to other architectures for similar
reasons.

No attempt is made to provide ESR_ELx to userspace in the signal
frame, since architectural limitations mean that it is unlikely to
provide much diagnostic value, doesn't benefit existing software
and would create ABI with no proven purpose.  The existing
mechanism for passing it also has problems of its own which may
result in the wrong value being passed to userspace due to
interaction with mm faults.  The implied rework does not appear
justified.

Reported-by: Eric W. Biederman <ebiederm@xmission.com>
Signed-off-by: Dave Martin <Dave.Martin@arm.com>
---
 arch/arm64/include/asm/esr.h       |  9 +++++++++
 arch/arm64/kernel/fpsimd.c         | 27 +++++++++++++++------------
 include/uapi/asm-generic/siginfo.h |  3 ++-
 3 files changed, 26 insertions(+), 13 deletions(-)

diff --git a/arch/arm64/include/asm/esr.h b/arch/arm64/include/asm/esr.h
index 014d7d8..c585e91 100644
--- a/arch/arm64/include/asm/esr.h
+++ b/arch/arm64/include/asm/esr.h
@@ -220,6 +220,15 @@
 		(((e) & ESR_ELx_SYS64_ISS_OP2_MASK) >>		\
 		 ESR_ELx_SYS64_ISS_OP2_SHIFT))
 
+/*
+ * ISS field definitions for floating-point exception traps
+ * (FP_EXC_32/FP_EXC_64).
+ *
+ * (The FPEXC_* constants are used instead for common bits.)
+ */
+
+#define ESR_ELx_FP_EXC_TFV	(UL(1) << 23)
+
 #ifndef __ASSEMBLY__
 #include <asm/types.h>
 
diff --git a/arch/arm64/kernel/fpsimd.c b/arch/arm64/kernel/fpsimd.c
index fae81f7..2d6ba9e 100644
--- a/arch/arm64/kernel/fpsimd.c
+++ b/arch/arm64/kernel/fpsimd.c
@@ -39,6 +39,7 @@
 #include <linux/slab.h>
 #include <linux/sysctl.h>
 
+#include <asm/esr.h>
 #include <asm/fpsimd.h>
 #include <asm/cputype.h>
 #include <asm/simd.h>
@@ -867,18 +868,20 @@ asmlinkage void do_fpsimd_acc(unsigned int esr, struct pt_regs *regs)
 asmlinkage void do_fpsimd_exc(unsigned int esr, struct pt_regs *regs)
 {
 	siginfo_t info;
-	unsigned int si_code = 0;
-
-	if (esr & FPEXC_IOF)
-		si_code = FPE_FLTINV;
-	else if (esr & FPEXC_DZF)
-		si_code = FPE_FLTDIV;
-	else if (esr & FPEXC_OFF)
-		si_code = FPE_FLTOVF;
-	else if (esr & FPEXC_UFF)
-		si_code = FPE_FLTUND;
-	else if (esr & FPEXC_IXF)
-		si_code = FPE_FLTRES;
+	unsigned int si_code = FPE_UNKNOWN;
+
+	if (esr & ESR_ELx_FP_EXC_TFV) {
+		if (esr & FPEXC_IOF)
+			si_code = FPE_FLTINV;
+		else if (esr & FPEXC_DZF)
+			si_code = FPE_FLTDIV;
+		else if (esr & FPEXC_OFF)
+			si_code = FPE_FLTOVF;
+		else if (esr & FPEXC_UFF)
+			si_code = FPE_FLTUND;
+		else if (esr & FPEXC_IXF)
+			si_code = FPE_FLTRES;
+	}
 
 	memset(&info, 0, sizeof(info));
 	info.si_signo = SIGFPE;
diff --git a/include/uapi/asm-generic/siginfo.h b/include/uapi/asm-generic/siginfo.h
index e447283..77edb00 100644
--- a/include/uapi/asm-generic/siginfo.h
+++ b/include/uapi/asm-generic/siginfo.h
@@ -193,7 +193,8 @@ typedef struct siginfo {
 #define FPE_FLTRES	6	/* floating point inexact result */
 #define FPE_FLTINV	7	/* floating point invalid operation */
 #define FPE_FLTSUB	8	/* subscript out of range */
-#define NSIGFPE		8
+#define FPE_UNKNOWN	9	/* undiagnosed floating-point exception */
+#define NSIGFPE		9
 
 /*
  * SIGSEGV si_codes
-- 
2.1.4

Re: [RFC PATCH 1/2] arm64: fpsimd: Fix bad si_code for undiagnosed SIGFPE

[Eric W. Biederman]

> diff --git a/include/uapi/asm-generic/siginfo.h b/include/uapi/asm-generic/siginfo.h
> index e447283..77edb00 100644
> --- a/include/uapi/asm-generic/siginfo.h
> +++ b/include/uapi/asm-generic/siginfo.h
> @@ -193,7 +193,8 @@ typedef struct siginfo {
>  #define FPE_FLTRES	6	/* floating point inexact result */
>  #define FPE_FLTINV	7	/* floating point invalid operation */
>  #define FPE_FLTSUB	8	/* subscript out of range */
> -#define NSIGFPE		8
> +#define FPE_UNKNOWN	9	/* undiagnosed floating-point exception */
> +#define NSIGFPE		9

Minor nit here.

At least before this is final I would really appreciate if you could
rebase this on top of my unificiation of siginfo.h that I posted on
linux-arch and is in my siginfo-next branch.

As that already pushes NSIGFPE up to 13.

Which would make this patch change NSIGFPE to 14 and allocate the number
14 for FPE_UNKNOWN

Eric

Re: [RFC PATCH 1/2] arm64: fpsimd: Fix bad si_code for undiagnosed SIGFPE

[Dave Martin]

On Mon, Jan 22, 2018 at 03:13:08PM -0600, Eric W. Biederman wrote:
> 
> > diff --git a/include/uapi/asm-generic/siginfo.h b/include/uapi/asm-generic/siginfo.h
> > index e447283..77edb00 100644
> > --- a/include/uapi/asm-generic/siginfo.h
> > +++ b/include/uapi/asm-generic/siginfo.h
> > @@ -193,7 +193,8 @@ typedef struct siginfo {
> >  #define FPE_FLTRES	6	/* floating point inexact result */
> >  #define FPE_FLTINV	7	/* floating point invalid operation */
> >  #define FPE_FLTSUB	8	/* subscript out of range */
> > -#define NSIGFPE		8
> > +#define FPE_UNKNOWN	9	/* undiagnosed floating-point exception */
> > +#define NSIGFPE		9
> 
> Minor nit here.
> 
> At least before this is final I would really appreciate if you could
> rebase this on top of my unificiation of siginfo.h that I posted on
> linux-arch and is in my siginfo-next branch.
> 
> As that already pushes NSIGFPE up to 13.
> 
> Which would make this patch change NSIGFPE to 14 and allocate the number
> 14 for FPE_UNKNOWN

My bad -- I hadn't looked in detail at the whole series.

However, the purpose of this as an RFC was to get feedback on whether
adding FPE_UNKNOWN is considered acceptable at all from an API
perspective -- the precise number doesn't matter for that discussion.

Do you have any view on this?

Cheers
---Dave

Re: [RFC PATCH 1/2] arm64: fpsimd: Fix bad si_code for undiagnosed SIGFPE

[Eric W. Biederman]

Dave Martin <Dave.Martin-5wv7dgnIgG8@public.gmane.org> writes:

> On Mon, Jan 22, 2018 at 03:13:08PM -0600, Eric W. Biederman wrote:
>> 
>> > diff --git a/include/uapi/asm-generic/siginfo.h b/include/uapi/asm-generic/siginfo.h
>> > index e447283..77edb00 100644
>> > --- a/include/uapi/asm-generic/siginfo.h
>> > +++ b/include/uapi/asm-generic/siginfo.h
>> > @@ -193,7 +193,8 @@ typedef struct siginfo {
>> >  #define FPE_FLTRES	6	/* floating point inexact result */
>> >  #define FPE_FLTINV	7	/* floating point invalid operation */
>> >  #define FPE_FLTSUB	8	/* subscript out of range */
>> > -#define NSIGFPE		8
>> > +#define FPE_UNKNOWN	9	/* undiagnosed floating-point exception */
>> > +#define NSIGFPE		9
>> 
>> Minor nit here.
>> 
>> At least before this is final I would really appreciate if you could
>> rebase this on top of my unificiation of siginfo.h that I posted on
>> linux-arch and is in my siginfo-next branch.
>> 
>> As that already pushes NSIGFPE up to 13.
>> 
>> Which would make this patch change NSIGFPE to 14 and allocate the number
>> 14 for FPE_UNKNOWN
>
> My bad -- I hadn't looked in detail at the whole series.
>
> However, the purpose of this as an RFC was to get feedback on whether
> adding FPE_UNKNOWN is considered acceptable at all from an API
> perspective -- the precise number doesn't matter for that discussion.
>
> Do you have any view on this?

That seems as good a solution as any too me.  It is reality and it
happens in the code and there are several places of the same form I
would use it, just to get rid of the FPE_FIXME.

Eric

Re: [RFC PATCH 1/2] arm64: fpsimd: Fix bad si_code for undiagnosed SIGFPE

[David Miller]

From: ebiederm-aS9lmoZGLiVWk0Htik3J/w@public.gmane.org (Eric W. Biederman)
Date: Tue, 23 Jan 2018 12:27:16 -0600

> Dave Martin <Dave.Martin-5wv7dgnIgG8@public.gmane.org> writes:
> 
>> On Mon, Jan 22, 2018 at 03:13:08PM -0600, Eric W. Biederman wrote:
>> However, the purpose of this as an RFC was to get feedback on whether
>> adding FPE_UNKNOWN is considered acceptable at all from an API
>> perspective -- the precise number doesn't matter for that discussion.
>>
>> Do you have any view on this?
> 
> That seems as good a solution as any too me.  It is reality and it
> happens in the code and there are several places of the same form I
> would use it, just to get rid of the FPE_FIXME.

Eric, feel free to do something similar on Sparc.

Re: [RFC PATCH 1/2] arm64: fpsimd: Fix bad si_code for undiagnosed SIGFPE

[Eric W. Biederman]

David Miller <davem@davemloft.net> writes:

> From: ebiederm@xmission.com (Eric W. Biederman)
> Date: Tue, 23 Jan 2018 12:27:16 -0600
>
>> Dave Martin <Dave.Martin@arm.com> writes:
>> 
>>> On Mon, Jan 22, 2018 at 03:13:08PM -0600, Eric W. Biederman wrote:
>>> However, the purpose of this as an RFC was to get feedback on whether
>>> adding FPE_UNKNOWN is considered acceptable at all from an API
>>> perspective -- the precise number doesn't matter for that discussion.
>>>
>>> Do you have any view on this?
>> 
>> That seems as good a solution as any too me.  It is reality and it
>> happens in the code and there are several places of the same form I
>> would use it, just to get rid of the FPE_FIXME.
>
> Eric, feel free to do something similar on Sparc.

Will do.

This sounds like a good solution for this weird corner case, that
appears on multiple architectures.

Eric

Re: [RFC PATCH 1/2] arm64: fpsimd: Fix bad si_code for undiagnosed SIGFPE

[Dave Martin]

On Tue, Jan 23, 2018 at 01:44:19PM -0600, Eric W. Biederman wrote:
> David Miller <davem-fT/PcQaiUtIeIZ0/mPfg9Q@public.gmane.org> writes:
> 
> > From: ebiederm-aS9lmoZGLiVWk0Htik3J/w@public.gmane.org (Eric W. Biederman)
> > Date: Tue, 23 Jan 2018 12:27:16 -0600
> >
> >> Dave Martin <Dave.Martin-5wv7dgnIgG8@public.gmane.org> writes:
> >> 
> >>> On Mon, Jan 22, 2018 at 03:13:08PM -0600, Eric W. Biederman wrote:
> >>> However, the purpose of this as an RFC was to get feedback on whether
> >>> adding FPE_UNKNOWN is considered acceptable at all from an API
> >>> perspective -- the precise number doesn't matter for that discussion.
> >>>
> >>> Do you have any view on this?
> >> 
> >> That seems as good a solution as any too me.  It is reality and it
> >> happens in the code and there are several places of the same form I
> >> would use it, just to get rid of the FPE_FIXME.
> >
> > Eric, feel free to do something similar on Sparc.
> 
> Will do.
> 
> This sounds like a good solution for this weird corner case, that
> appears on multiple architectures.

OK, I'll rebase my patches onto your tree (though trivial here) and
repost.

I'm still waiting for feeback on the Arm specifics, but FPE_UNKNOWN
could be picked up independently of that.

Cheers
---Dave

Re: [RFC PATCH 1/2] arm64: fpsimd: Fix bad si_code for undiagnosed SIGFPE

[Dave Martin]

On Mon, Jan 22, 2018 at 03:13:08PM -0600, Eric W. Biederman wrote:
> 
> > diff --git a/include/uapi/asm-generic/siginfo.h b/include/uapi/asm-generic/siginfo.h
> > index e447283..77edb00 100644
> > --- a/include/uapi/asm-generic/siginfo.h
> > +++ b/include/uapi/asm-generic/siginfo.h
> > @@ -193,7 +193,8 @@ typedef struct siginfo {
> >  #define FPE_FLTRES	6	/* floating point inexact result */
> >  #define FPE_FLTINV	7	/* floating point invalid operation */
> >  #define FPE_FLTSUB	8	/* subscript out of range */
> > -#define NSIGFPE		8
> > +#define FPE_UNKNOWN	9	/* undiagnosed floating-point exception */
> > +#define NSIGFPE		9
> 
> Minor nit here.
> 
> At least before this is final I would really appreciate if you could
> rebase this on top of my unificiation of siginfo.h that I posted on
> linux-arch and is in my siginfo-next branch.
> 
> As that already pushes NSIGFPE up to 13.
> 
> Which would make this patch change NSIGFPE to 14 and allocate the number
> 14 for FPE_UNKNOWN

Looking at this, I note a few things:

 * For consistent naming, FPE_FLTUNK might be a better name for
   FPE_UNKNOWN.

   FPE_FLTUNK seems generic, tempting me to insert it as number 9
   (since only the numbers up to 8 are ABI just now).

   (The temptation to call it FPE_FLUNK is strong, but I can't argue
   that's consistent...)

 * No distinction is drawn between generic and arch-dependent codes
   here, so NSIGFPE will typically be too big.  The generic siginfo
   handling code can detect random garbage in si_code this way, but
   off-by-ones or misused arch-specific codes may slip through.

   In particular, new x86-specific FPE_* codes will likely be
   invisible to the BUILD_BUG_ON()s in arch/x86/kernel/signal_compat.c
   unless so many are added that x86 overtakes ia64.

 * Should we reserve space for future generic codes (say up to 15)?
   Downside: si_code validation is not a simple matter of checking
   <= NSIGFPE in that case.  (Though <= is still better than no
   check at all, and no worse than the current situation.)

 * What are NSIGFPE etc. doing in this header?  These aren't specified
   by POSIX and I'm not sure what userspace would legitimately use them
   for... though it may be too late to change this now.

   Most instances on codeseaarch.debian.net are the kernel, copies
   of kernel headers, and translated versions of kernel headers.
   It's hard to be exhaustive though.


We could have something like this:

#define FPE_FLTUNK	9
#define __NSIGFPE_GENERIC	9
#define NSIGFPE		__NSIGFPE_GENERIC

/* si_code <= 15 reserved for arch-independent codes */

#if defined(__frv__)

# define FPE_MDAOF	16
# undef NSIGFPE
# define NSIGFPE	16

#elif define(__ia64__)

# define __FPE_DECOVF	16
# define __FPE_DECDIV	17
# define __FPE_DECERR	18
# define __FPR_INVASC	19
# undef NSIGFPE
# define NSIGFPE	19

#endif

(Avoiding a (base + offset) approach for the arch codes, since that
would make it look like the codes can be renumbered safely without
breaking anything).

The generic vs. arch vs. NSIGFOO problem already exists for other
signals.  We could take a similar approach for those, but OTOH it
may just not be worth the effort.

Cheers
---Dave

Re: [RFC PATCH 1/2] arm64: fpsimd: Fix bad si_code for undiagnosed SIGFPE

[Eric W. Biederman]

Dave Martin <Dave.Martin-5wv7dgnIgG8@public.gmane.org> writes:

> On Mon, Jan 22, 2018 at 03:13:08PM -0600, Eric W. Biederman wrote:
>> 
>> > diff --git a/include/uapi/asm-generic/siginfo.h b/include/uapi/asm-generic/siginfo.h
>> > index e447283..77edb00 100644
>> > --- a/include/uapi/asm-generic/siginfo.h
>> > +++ b/include/uapi/asm-generic/siginfo.h
>> > @@ -193,7 +193,8 @@ typedef struct siginfo {
>> >  #define FPE_FLTRES	6	/* floating point inexact result */
>> >  #define FPE_FLTINV	7	/* floating point invalid operation */
>> >  #define FPE_FLTSUB	8	/* subscript out of range */
>> > -#define NSIGFPE		8
>> > +#define FPE_UNKNOWN	9	/* undiagnosed floating-point exception */
>> > +#define NSIGFPE		9
>> 
>> Minor nit here.
>> 
>> At least before this is final I would really appreciate if you could
>> rebase this on top of my unificiation of siginfo.h that I posted on
>> linux-arch and is in my siginfo-next branch.
>> 
>> As that already pushes NSIGFPE up to 13.
>> 
>> Which would make this patch change NSIGFPE to 14 and allocate the number
>> 14 for FPE_UNKNOWN
>
> Looking at this, I note a few things:
>
>  * For consistent naming, FPE_FLTUNK might be a better name for
>    FPE_UNKNOWN.
>
>    FPE_FLTUNK seems generic, tempting me to insert it as number 9
>    (since only the numbers up to 8 are ABI just now).

Except on ia64 and frv.  And who knows we might need it on one of those
architectures as well.

>    (The temptation to call it FPE_FLUNK is strong, but I can't argue
>    that's consistent...)

I totally understand the temptation.

>  * No distinction is drawn between generic and arch-dependent codes
>    here, so NSIGFPE will typically be too big.  The generic siginfo
>    handling code can detect random garbage in si_code this way, but
>    off-by-ones or misused arch-specific codes may slip through.
>
>    In particular, new x86-specific FPE_* codes will likely be
>    invisible to the BUILD_BUG_ON()s in arch/x86/kernel/signal_compat.c
>    unless so many are added that x86 overtakes ia64.

Long ago in a far off time, we had arch dependent system call numbers
and the like because that provided ABI compatibility with the existing
unix on the platform.

I don't see any of that with the siginfo si_codes.   In most cases
they are arch dependent extensions which is silly.  We should have
unconditionally extended the si_codes for all architectures in case
another architecture needs that si_code.

The fact we now have battling meanings for si_codes depending on the
architecture is an unfortunate mess.

So to me it looks most maintainable going forward to declare that all
si_codes should be allocated generically, from the same number space,
in the same header file.  While we live with the existing historic
mess.

>  * Should we reserve space for future generic codes (say up to 15)?
>    Downside: si_code validation is not a simple matter of checking
>    <= NSIGFPE in that case.  (Though <= is still better than no
>    check at all, and no worse than the current situation.)

I think new si_codes should be allocated where there are not conflicts
on any architecture.  Just in case they are useful on another
architecture in the future.

>  * What are NSIGFPE etc. doing in this header?  These aren't specified
>    by POSIX and I'm not sure what userspace would legitimately use them
>    for... though it may be too late to change this now.
>
>    Most instances on codeseaarch.debian.net are the kernel, copies
>    of kernel headers, and translated versions of kernel headers.
>    It's hard to be exhaustive though.
>
>
> We could have something like this:
>
> #define FPE_FLTUNK	9
> #define __NSIGFPE_GENERIC	9
> #define NSIGFPE		__NSIGFPE_GENERIC
>
> /* si_code <= 15 reserved for arch-independent codes */
>
> #if defined(__frv__)
>
> # define FPE_MDAOF	16
> # undef NSIGFPE
> # define NSIGFPE	16
>
> #elif define(__ia64__)
>
> # define __FPE_DECOVF	16
> # define __FPE_DECDIV	17
> # define __FPE_DECERR	18
> # define __FPR_INVASC	19
> # undef NSIGFPE
> # define NSIGFPE	19
>
> #endif
>
> (Avoiding a (base + offset) approach for the arch codes, since that
> would make it look like the codes can be renumbered safely without
> breaking anything).
>
> The generic vs. arch vs. NSIGFOO problem already exists for other
> signals.  We could take a similar approach for those, but OTOH it
> may just not be worth the effort.

What I have tried to do in my merger is discurage the idea that there
are any arch specific si_codes.  To set NSIGXXX to the largest value
from any of the architectures.  And to encourage new si_codes get
allocated after the current NSIGXXX.  So that they will work on all
architectures.

It is all a bit of a mess, but one unified mess seems like the best we
can do right now.

Eric

Re: [RFC PATCH 1/2] arm64: fpsimd: Fix bad si_code for undiagnosed SIGFPE

[Dave Martin]

On Wed, Jan 24, 2018 at 10:47:36AM -0600, Eric W. Biederman wrote:
> Dave Martin <Dave.Martin@arm.com> writes:
> 
> > On Mon, Jan 22, 2018 at 03:13:08PM -0600, Eric W. Biederman wrote:
> >> 
> >> > diff --git a/include/uapi/asm-generic/siginfo.h b/include/uapi/asm-generic/siginfo.h
> >> > index e447283..77edb00 100644
> >> > --- a/include/uapi/asm-generic/siginfo.h
> >> > +++ b/include/uapi/asm-generic/siginfo.h
> >> > @@ -193,7 +193,8 @@ typedef struct siginfo {
> >> >  #define FPE_FLTRES	6	/* floating point inexact result */
> >> >  #define FPE_FLTINV	7	/* floating point invalid operation */
> >> >  #define FPE_FLTSUB	8	/* subscript out of range */
> >> > -#define NSIGFPE		8
> >> > +#define FPE_UNKNOWN	9	/* undiagnosed floating-point exception */
> >> > +#define NSIGFPE		9
> >> 
> >> Minor nit here.
> >> 
> >> At least before this is final I would really appreciate if you could
> >> rebase this on top of my unificiation of siginfo.h that I posted on
> >> linux-arch and is in my siginfo-next branch.
> >> 
> >> As that already pushes NSIGFPE up to 13.
> >> 
> >> Which would make this patch change NSIGFPE to 14 and allocate the number
> >> 14 for FPE_UNKNOWN
> >
> > Looking at this, I note a few things:
> >
> >  * For consistent naming, FPE_FLTUNK might be a better name for
> >    FPE_UNKNOWN.
> >
> >    FPE_FLTUNK seems generic, tempting me to insert it as number 9
> >    (since only the numbers up to 8 are ABI just now).
> 
> Except on ia64 and frv.  And who knows we might need it on one of those
> architectures as well.

I thought those weren't actually upstreamed yet...

> >    (The temptation to call it FPE_FLUNK is strong, but I can't argue
> >    that's consistent...)
> 
> I totally understand the temptation.
> 
> >  * No distinction is drawn between generic and arch-dependent codes
> >    here, so NSIGFPE will typically be too big.  The generic siginfo
> >    handling code can detect random garbage in si_code this way, but
> >    off-by-ones or misused arch-specific codes may slip through.
> >
> >    In particular, new x86-specific FPE_* codes will likely be
> >    invisible to the BUILD_BUG_ON()s in arch/x86/kernel/signal_compat.c
> >    unless so many are added that x86 overtakes ia64.
> 
> Long ago in a far off time, we had arch dependent system call numbers
> and the like because that provided ABI compatibility with the existing
> unix on the platform.
> 
> I don't see any of that with the siginfo si_codes.   In most cases
> they are arch dependent extensions which is silly.  We should have
> unconditionally extended the si_codes for all architectures in case
> another architecture needs that si_code.
> 
> The fact we now have battling meanings for si_codes depending on the
> architecture is an unfortunate mess.
> 
> So to me it looks most maintainable going forward to declare that all
> si_codes should be allocated generically, from the same number space,
> in the same header file.  While we live with the existing historic
> mess.

I guess that's fair enough.  This also provides a consistent
interpretation for NSIGXXX.

> >  * Should we reserve space for future generic codes (say up to 15)?
> >    Downside: si_code validation is not a simple matter of checking
> >    <= NSIGFPE in that case.  (Though <= is still better than no
> >    check at all, and no worse than the current situation.)
> 
> I think new si_codes should be allocated where there are not conflicts
> on any architecture.  Just in case they are useful on another
> architecture in the future.
> 
> >  * What are NSIGFPE etc. doing in this header?  These aren't specified
> >    by POSIX and I'm not sure what userspace would legitimately use them
> >    for... though it may be too late to change this now.
> >
> >    Most instances on codeseaarch.debian.net are the kernel, copies
> >    of kernel headers, and translated versions of kernel headers.
> >    It's hard to be exhaustive though.
> >
> >
> > We could have something like this:
> >
> > #define FPE_FLTUNK	9
> > #define __NSIGFPE_GENERIC	9
> > #define NSIGFPE		__NSIGFPE_GENERIC
> >
> > /* si_code <= 15 reserved for arch-independent codes */
> >
> > #if defined(__frv__)
> >
> > # define FPE_MDAOF	16
> > # undef NSIGFPE
> > # define NSIGFPE	16
> >
> > #elif define(__ia64__)
> >
> > # define __FPE_DECOVF	16
> > # define __FPE_DECDIV	17
> > # define __FPE_DECERR	18
> > # define __FPR_INVASC	19
> > # undef NSIGFPE
> > # define NSIGFPE	19
> >
> > #endif
> >
> > (Avoiding a (base + offset) approach for the arch codes, since that
> > would make it look like the codes can be renumbered safely without
> > breaking anything).
> >
> > The generic vs. arch vs. NSIGFOO problem already exists for other
> > signals.  We could take a similar approach for those, but OTOH it
> > may just not be worth the effort.
> 
> What I have tried to do in my merger is discurage the idea that there
> are any arch specific si_codes.  To set NSIGXXX to the largest value
> from any of the architectures.  And to encourage new si_codes get
> allocated after the current NSIGXXX.  So that they will work on all
> architectures.
> 
> It is all a bit of a mess, but one unified mess seems like the best we
> can do right now.

That sounds fair, now that I have a better understanding of the context
for all this.

If the policy is that all the codes are generic (even if not all can
happen on all arches) then FPE_FLTUNK may as well be 14.

Cheers
---Dave

Re: [RFC PATCH 1/2] arm64: fpsimd: Fix bad si_code for undiagnosed SIGFPE

[Eric W. Biederman]

Dave Martin <Dave.Martin@arm.com> writes:

> On Wed, Jan 24, 2018 at 10:47:36AM -0600, Eric W. Biederman wrote:
>> Dave Martin <Dave.Martin@arm.com> writes:
>> 
>> > On Mon, Jan 22, 2018 at 03:13:08PM -0600, Eric W. Biederman wrote:
>> >> 
>> >> > diff --git a/include/uapi/asm-generic/siginfo.h b/include/uapi/asm-generic/siginfo.h
>> >> > index e447283..77edb00 100644
>> >> > --- a/include/uapi/asm-generic/siginfo.h
>> >> > +++ b/include/uapi/asm-generic/siginfo.h
>> >> > @@ -193,7 +193,8 @@ typedef struct siginfo {
>> >> >  #define FPE_FLTRES	6	/* floating point inexact result */
>> >> >  #define FPE_FLTINV	7	/* floating point invalid operation */
>> >> >  #define FPE_FLTSUB	8	/* subscript out of range */
>> >> > -#define NSIGFPE		8
>> >> > +#define FPE_UNKNOWN	9	/* undiagnosed floating-point exception */
>> >> > +#define NSIGFPE		9
>> >> 
>> >> Minor nit here.
>> >> 
>> >> At least before this is final I would really appreciate if you could
>> >> rebase this on top of my unificiation of siginfo.h that I posted on
>> >> linux-arch and is in my siginfo-next branch.
>> >> 
>> >> As that already pushes NSIGFPE up to 13.
>> >> 
>> >> Which would make this patch change NSIGFPE to 14 and allocate the number
>> >> 14 for FPE_UNKNOWN
>> >
>> > Looking at this, I note a few things:
>> >
>> >  * For consistent naming, FPE_FLTUNK might be a better name for
>> >    FPE_UNKNOWN.
>> >
>> >    FPE_FLTUNK seems generic, tempting me to insert it as number 9
>> >    (since only the numbers up to 8 are ABI just now).
>> 
>> Except on ia64 and frv.  And who knows we might need it on one of those
>> architectures as well.
>
> I thought those weren't actually upstreamed yet...

Oh no.  Those have been upstream for a decade or so.  They just have not
been in one unified file.

>> >    (The temptation to call it FPE_FLUNK is strong, but I can't argue
>> >    that's consistent...)
>> 
>> I totally understand the temptation.
>> 
>> >  * No distinction is drawn between generic and arch-dependent codes
>> >    here, so NSIGFPE will typically be too big.  The generic siginfo
>> >    handling code can detect random garbage in si_code this way, but
>> >    off-by-ones or misused arch-specific codes may slip through.
>> >
>> >    In particular, new x86-specific FPE_* codes will likely be
>> >    invisible to the BUILD_BUG_ON()s in arch/x86/kernel/signal_compat.c
>> >    unless so many are added that x86 overtakes ia64.
>> 
>> Long ago in a far off time, we had arch dependent system call numbers
>> and the like because that provided ABI compatibility with the existing
>> unix on the platform.
>> 
>> I don't see any of that with the siginfo si_codes.   In most cases
>> they are arch dependent extensions which is silly.  We should have
>> unconditionally extended the si_codes for all architectures in case
>> another architecture needs that si_code.
>> 
>> The fact we now have battling meanings for si_codes depending on the
>> architecture is an unfortunate mess.
>> 
>> So to me it looks most maintainable going forward to declare that all
>> si_codes should be allocated generically, from the same number space,
>> in the same header file.  While we live with the existing historic
>> mess.
>
> I guess that's fair enough.  This also provides a consistent
> interpretation for NSIGXXX.
>
>> >  * Should we reserve space for future generic codes (say up to 15)?
>> >    Downside: si_code validation is not a simple matter of checking
>> >    <= NSIGFPE in that case.  (Though <= is still better than no
>> >    check at all, and no worse than the current situation.)
>> 
>> I think new si_codes should be allocated where there are not conflicts
>> on any architecture.  Just in case they are useful on another
>> architecture in the future.
>> 
>> >  * What are NSIGFPE etc. doing in this header?  These aren't specified
>> >    by POSIX and I'm not sure what userspace would legitimately use them
>> >    for... though it may be too late to change this now.
>> >
>> >    Most instances on codeseaarch.debian.net are the kernel, copies
>> >    of kernel headers, and translated versions of kernel headers.
>> >    It's hard to be exhaustive though.
>> >
>> >
>> > We could have something like this:
>> >
>> > #define FPE_FLTUNK	9
>> > #define __NSIGFPE_GENERIC	9
>> > #define NSIGFPE		__NSIGFPE_GENERIC
>> >
>> > /* si_code <= 15 reserved for arch-independent codes */
>> >
>> > #if defined(__frv__)
>> >
>> > # define FPE_MDAOF	16
>> > # undef NSIGFPE
>> > # define NSIGFPE	16
>> >
>> > #elif define(__ia64__)
>> >
>> > # define __FPE_DECOVF	16
>> > # define __FPE_DECDIV	17
>> > # define __FPE_DECERR	18
>> > # define __FPR_INVASC	19
>> > # undef NSIGFPE
>> > # define NSIGFPE	19
>> >
>> > #endif
>> >
>> > (Avoiding a (base + offset) approach for the arch codes, since that
>> > would make it look like the codes can be renumbered safely without
>> > breaking anything).
>> >
>> > The generic vs. arch vs. NSIGFOO problem already exists for other
>> > signals.  We could take a similar approach for those, but OTOH it
>> > may just not be worth the effort.
>> 
>> What I have tried to do in my merger is discurage the idea that there
>> are any arch specific si_codes.  To set NSIGXXX to the largest value
>> from any of the architectures.  And to encourage new si_codes get
>> allocated after the current NSIGXXX.  So that they will work on all
>> architectures.
>> 
>> It is all a bit of a mess, but one unified mess seems like the best we
>> can do right now.
>
> That sounds fair, now that I have a better understanding of the context
> for all this.
>
> If the policy is that all the codes are generic (even if not all can
> happen on all arches) then FPE_FLTUNK may as well be 14.

Exactly.

Eric

[RFC PATCH 2/2] arm64: signal: Ensure si_code is valid for all fault signals

[Dave Martin]

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-aS9lmoZGLiVWk0Htik3J/w@public.gmane.org>
Signed-off-by: Dave Martin <Dave.Martin-5wv7dgnIgG8@public.gmane.org>
---
 arch/arm64/kernel/fpsimd.c |   4 +-
 arch/arm64/mm/fault.c      | 114 ++++++++++++++++++++++-----------------------
 2 files changed, 59 insertions(+), 59 deletions(-)

diff --git a/arch/arm64/kernel/fpsimd.c b/arch/arm64/kernel/fpsimd.c
index 2d6ba9e..7ce23e0 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,
-- 
2.1.4