[4/7] signal/mips: Document a conflict with SI_USER with SIGFPE

Submitted by Eric W. Biederman on July 18, 2017, 2:06 p.m.

Details

Message ID 20170718140651.15973-4-ebiederm@xmission.com
State New
Series "Series without cover letter"
Headers show

Commit Message

Eric W. Biederman July 18, 2017, 2:06 p.m.
Setting si_code to __SI_FAULT 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.

This use of of __SI_FAULT is only a decade old.  Which compared
to the other pieces of kernel code that has made this mistake
is almost yesterday.

This is probably worth fixing but I don't know mips well enough
to know what si_code to would be the proper one to use.

Cc: Ralf Baechle <ralf@linux-mips.org>
Ref: 948a34cf3988 ("[MIPS] Maintain si_code field properly for FP exceptions")
Signed-off-by: "Eric W. Biederman" <ebiederm@xmission.com>
---
 arch/mips/include/uapi/asm/siginfo.h | 7 +++++++
 arch/mips/kernel/traps.c             | 2 +-
 2 files changed, 8 insertions(+), 1 deletion(-)

Patch hide | download patch | download mbox

diff --git a/arch/mips/include/uapi/asm/siginfo.h b/arch/mips/include/uapi/asm/siginfo.h
index 8069cf766603..9becfd102132 100644
--- a/arch/mips/include/uapi/asm/siginfo.h
+++ b/arch/mips/include/uapi/asm/siginfo.h
@@ -123,4 +123,11 @@  typedef struct siginfo {
 #define SI_TIMER __SI_CODE(__SI_TIMER, -3) /* sent by timer expiration */
 #define SI_MESGQ __SI_CODE(__SI_MESGQ, -4) /* sent by real time mesq state change */
 
+/*
+ * SIGFPE si_codes
+ */
+#ifdef __KERNEL__
+#define FPE_FIXME	(__SI_FAULT|0)	/* Broken dup of SI_USER */
+#endif /* __KERNEL__ */
+
 #endif /* _UAPI_ASM_SIGINFO_H */
diff --git a/arch/mips/kernel/traps.c b/arch/mips/kernel/traps.c
index b68b4d0726d3..6c9cca9c5341 100644
--- a/arch/mips/kernel/traps.c
+++ b/arch/mips/kernel/traps.c
@@ -735,7 +735,7 @@  void force_fcr31_sig(unsigned long fcr31, void __user *fault_addr,
 	else if (fcr31 & FPU_CSR_INE_X)
 		si.si_code = FPE_FLTRES;
 	else
-		si.si_code = __SI_FAULT;
+		si.si_code = FPE_FIXME;
 	force_sig_info(SIGFPE, &si, tsk);
 }
 

Comments

Maciej W. Rozycki Aug. 7, 2017, 4:18 p.m.
On Tue, 18 Jul 2017, Eric W. Biederman wrote:

> diff --git a/arch/mips/kernel/traps.c b/arch/mips/kernel/traps.c
> index b68b4d0726d3..6c9cca9c5341 100644
> --- a/arch/mips/kernel/traps.c
> +++ b/arch/mips/kernel/traps.c
> @@ -735,7 +735,7 @@ void force_fcr31_sig(unsigned long fcr31, void __user *fault_addr,
>  	else if (fcr31 & FPU_CSR_INE_X)
>  		si.si_code = FPE_FLTRES;
>  	else
> -		si.si_code = __SI_FAULT;
> +		si.si_code = FPE_FIXME;

 This is an "impossible" state to reach unless your hardware is on fire.  
One or more of the FCSR Cause bits will have been set (in `fcr31') or the 
FPE exception would not have happened.

 Of course there could be a simulator bug, or we could have breakage 
somewhere causing `process_fpemu_return' to be called with SIGFPE and 
inconsistent `fcr31'.  So we need to handle it somehow.

 So what would be the right value of `si_code' to use here for such an 
unexpected exception condition?  I think `BUG()' would be too big a 
hammer here.  Or wouldn't it?

  Maciej
Linus Torvalds Aug. 7, 2017, 5:41 p.m.
On Mon, Aug 7, 2017 at 9:18 AM, Maciej W. Rozycki <macro@imgtec.com> wrote:
>
>  So what would be the right value of `si_code' to use here for such an
> unexpected exception condition?  I think `BUG()' would be too big a
> hammer here.  Or wouldn't it?

Hell no. NEVER EVER BUG().

The only case to use BUG() is if there is some core data structure
(say, kernel stack) that is so corrupted that you know you cannot
continue. That's the *only* valid use.

If this is a "this condition cannot happen" issue, then just remove
the damn conditional. It's pointless. Adding a BUG() to show "this
cannot happen" is not acceptable.

                        Linus
Ralf Baechle Aug. 7, 2017, 7:55 p.m.
On Mon, Aug 07, 2017 at 10:41:39AM -0700, Linus Torvalds wrote:

> On Mon, Aug 7, 2017 at 9:18 AM, Maciej W. Rozycki <macro@imgtec.com> wrote:
> >
> >  So what would be the right value of `si_code' to use here for such an
> > unexpected exception condition?  I think `BUG()' would be too big a
> > hammer here.  Or wouldn't it?
> 
> Hell no. NEVER EVER BUG().
> 
> The only case to use BUG() is if there is some core data structure
> (say, kernel stack) that is so corrupted that you know you cannot
> continue. That's the *only* valid use.
> 
> If this is a "this condition cannot happen" issue, then just remove
> the damn conditional. It's pointless. Adding a BUG() to show "this
> cannot happen" is not acceptable.

I queued a patch to remove the code for 4.14.

  Ralf
Eric W. Biederman Aug. 8, 2017, 3:29 p.m.
"Maciej W. Rozycki" <macro@imgtec.com> writes:

> On Tue, 18 Jul 2017, Eric W. Biederman wrote:
>
>> diff --git a/arch/mips/kernel/traps.c b/arch/mips/kernel/traps.c
>> index b68b4d0726d3..6c9cca9c5341 100644
>> --- a/arch/mips/kernel/traps.c
>> +++ b/arch/mips/kernel/traps.c
>> @@ -735,7 +735,7 @@ void force_fcr31_sig(unsigned long fcr31, void __user *fault_addr,
>>  	else if (fcr31 & FPU_CSR_INE_X)
>>  		si.si_code = FPE_FLTRES;
>>  	else
>> -		si.si_code = __SI_FAULT;
>> +		si.si_code = FPE_FIXME;
>
>  This is an "impossible" state to reach unless your hardware is on fire.  
> One or more of the FCSR Cause bits will have been set (in `fcr31') or the 
> FPE exception would not have happened.
>
>  Of course there could be a simulator bug, or we could have breakage 
> somewhere causing `process_fpemu_return' to be called with SIGFPE and 
> inconsistent `fcr31'.  So we need to handle it somehow.
>
>  So what would be the right value of `si_code' to use here for such an 
> unexpected exception condition?  I think `BUG()' would be too big a 
> hammer here.  Or wouldn't it?

The possible solutions I can think of are:

WARN_ON_ONCE with a comment.

Add a new si_code to uapi/asm-generic/siginfo.h perhaps FPE_IMPOSSIBLE.
Like syscall numbers si_codes are cheap.

Call force_sig() instead of force_sig_info, using just a generic
si_code.

If this is truly impossible and the compiler doesn't complain just drop
the code.

Eric
Maciej W. Rozycki Aug. 8, 2017, 11:19 p.m.
On Tue, 8 Aug 2017, Eric W. Biederman wrote:

> >  This is an "impossible" state to reach unless your hardware is on fire.  
> > One or more of the FCSR Cause bits will have been set (in `fcr31') or the 
> > FPE exception would not have happened.
> >
> >  Of course there could be a simulator bug, or we could have breakage 
> > somewhere causing `process_fpemu_return' to be called with SIGFPE and 
> > inconsistent `fcr31'.  So we need to handle it somehow.
> >
> >  So what would be the right value of `si_code' to use here for such an 
> > unexpected exception condition?  I think `BUG()' would be too big a 
> > hammer here.  Or wouldn't it?
> 
> The possible solutions I can think of are:
> 
> WARN_ON_ONCE with a comment.
> 
> Add a new si_code to uapi/asm-generic/siginfo.h perhaps FPE_IMPOSSIBLE.
> Like syscall numbers si_codes are cheap.

 I think we ought to do both.

 First, we have our own FP emulation code, which is changed from time to 
time, that uses the same exit path that the hardware exception does.  It 
could happen that we miss something and return SIGFPE from the emulation 
code without setting the cause bits appropriately.  This would be our own 
bug which might trigger exceedingly rarely and could then be caught by 
WARN_ON_ONCE or otherwise stay there forever in the absence of that check.

 Second, changing `si_code' from __SI_FAULT to 0 aka __SI_KILL will likely 
interfere with `copy_siginfo_to_user32' in arch/mips/kernel/signal32.c, 
making the userland lose the address of the faulting instruction in 32-bit 
software run on 64-bit hardware only, making our API inconsistent.  Using 
a distinct `si_code' value such as FPE_IMPOSSIBLE (though we might choose 
say FPE_FLTUNK for "FLoaTing point UNKnown" instead, for consistency; mind 
that most `si_code' macros have the same number of characters within 
groups associated with individual signals) for such odd traps is allowed 
by SUS and will prevent the inconsistency from happening, very cheaply as 
you say.

  Maciej