All of lore.kernel.org
 help / color / mirror / Atom feed
* [PATCH] alpha: fix FEN fault handling
@ 2023-01-07  0:59 Al Viro
  2023-01-07  1:55 ` Richard Henderson
  0 siblings, 1 reply; 5+ messages in thread
From: Al Viro @ 2023-01-07  0:59 UTC (permalink / raw)
  To: linux-alpha; +Cc: Richard Henderson, linux-kernel

Type 3 instruction fault (FPU insn with FPU disabled) is handled
by quietly enabling FPU and returning.  Which is fine, except that
we need to do that both for fault in userland and in the kernel;
the latter *can* legitimately happen - all it takes is this:

.global _start
_start:
	call_pal 0xae
	lda $0, 0
	ldq $0, 0($0)

- call_pal CLRFEN to clear "FPU enabled" flag and arrange for
a signal delivery (SIGSEGV in this case).

Fixed by moving the handling of type 3 into the common part of
do_entIF(), before we check for kernel vs. user mode.

Incidentally, check for kernel mode is unidiomatic; the normal
way to do that is !user_mode(regs).  The difference is that
the open-coded variant treats any of bits 63..3 of regs->ps being
set as "it's user mode" while the normal approach is to check just
the bit 3.  PS is a 4-bit register and regs->ps always will have
bits 63..4 clear, so the open-code variant here is actually equivalent
to !user_mode(regs).  Harder to follow, though...

Reproducer above will crash any box where CLRFEN is not ignored by
PAL (== any actual hardware, AFAICS; PAL used in qemu doesn't
bother implementing that crap).

Cc: stable@vger.kernel.org # all way back...
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
---
diff --git a/arch/alpha/kernel/traps.c b/arch/alpha/kernel/traps.c
index 8a66fe544c69..d9a67b370e04 100644
--- a/arch/alpha/kernel/traps.c
+++ b/arch/alpha/kernel/traps.c
@@ -233,7 +233,21 @@ do_entIF(unsigned long type, struct pt_regs *regs)
 {
 	int signo, code;
 
-	if ((regs->ps & ~IPL_MAX) == 0) {
+	if (type == 3) { /* FEN fault */
+		/* Irritating users can call PAL_clrfen to disable the
+		   FPU for the process.  The kernel will then trap in
+		   do_switch_stack and undo_switch_stack when we try
+		   to save and restore the FP registers.
+
+		   Given that GCC by default generates code that uses the
+		   FP registers, PAL_clrfen is not useful except for DoS
+		   attacks.  So turn the bleeding FPU back on and be done
+		   with it.  */
+		current_thread_info()->pcb.flags |= 1;
+		__reload_thread(&current_thread_info()->pcb);
+		return;
+	}
+	if (!user_mode(regs)) {
 		if (type == 1) {
 			const unsigned int *data
 			  = (const unsigned int *) regs->pc;
@@ -366,20 +380,6 @@ do_entIF(unsigned long type, struct pt_regs *regs)
 		}
 		break;
 
-	      case 3: /* FEN fault */
-		/* Irritating users can call PAL_clrfen to disable the
-		   FPU for the process.  The kernel will then trap in
-		   do_switch_stack and undo_switch_stack when we try
-		   to save and restore the FP registers.
-
-		   Given that GCC by default generates code that uses the
-		   FP registers, PAL_clrfen is not useful except for DoS
-		   attacks.  So turn the bleeding FPU back on and be done
-		   with it.  */
-		current_thread_info()->pcb.flags |= 1;
-		__reload_thread(&current_thread_info()->pcb);
-		return;
-
 	      case 5: /* illoc */
 	      default: /* unexpected instruction-fault type */
 		      ;

^ permalink raw reply related	[flat|nested] 5+ messages in thread

* Re: [PATCH] alpha: fix FEN fault handling
  2023-01-07  0:59 [PATCH] alpha: fix FEN fault handling Al Viro
@ 2023-01-07  1:55 ` Richard Henderson
  2023-01-07  2:46   ` Al Viro
  0 siblings, 1 reply; 5+ messages in thread
From: Richard Henderson @ 2023-01-07  1:55 UTC (permalink / raw)
  To: Al Viro, linux-alpha; +Cc: linux-kernel

On 1/6/23 16:59, Al Viro wrote:
> Type 3 instruction fault (FPU insn with FPU disabled) is handled
> by quietly enabling FPU and returning.  Which is fine, except that
> we need to do that both for fault in userland and in the kernel;
> the latter *can* legitimately happen - all it takes is this:
> 
> .global _start
> _start:
> 	call_pal 0xae
> 	lda $0, 0
> 	ldq $0, 0($0)
> 
> - call_pal CLRFEN to clear "FPU enabled" flag and arrange for
> a signal delivery (SIGSEGV in this case).
> 
> Fixed by moving the handling of type 3 into the common part of
> do_entIF(), before we check for kernel vs. user mode.
> 
> Incidentally, check for kernel mode is unidiomatic; the normal
> way to do that is !user_mode(regs).  The difference is that
> the open-coded variant treats any of bits 63..3 of regs->ps being
> set as "it's user mode" while the normal approach is to check just
> the bit 3.  PS is a 4-bit register and regs->ps always will have
> bits 63..4 clear, so the open-code variant here is actually equivalent
> to !user_mode(regs).  Harder to follow, though...
> 
> Reproducer above will crash any box where CLRFEN is not ignored by
> PAL (== any actual hardware, AFAICS; PAL used in qemu doesn't
> bother implementing that crap).

I didn't realize I'd forgotten this in qemu.  Anyway,

Reviewed-by: Richard Henderson <rth@twiddle.net>


r~

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: [PATCH] alpha: fix FEN fault handling
  2023-01-07  1:55 ` Richard Henderson
@ 2023-01-07  2:46   ` Al Viro
  2023-01-07 21:28     ` Al Viro
  0 siblings, 1 reply; 5+ messages in thread
From: Al Viro @ 2023-01-07  2:46 UTC (permalink / raw)
  To: Richard Henderson; +Cc: linux-alpha, linux-kernel

On Fri, Jan 06, 2023 at 05:55:14PM -0800, Richard Henderson wrote:
> On 1/6/23 16:59, Al Viro wrote:
> > Type 3 instruction fault (FPU insn with FPU disabled) is handled
> > by quietly enabling FPU and returning.  Which is fine, except that
> > we need to do that both for fault in userland and in the kernel;
> > the latter *can* legitimately happen - all it takes is this:
> > 
> > .global _start
> > _start:
> > 	call_pal 0xae
> > 	lda $0, 0
> > 	ldq $0, 0($0)
> > 
> > - call_pal CLRFEN to clear "FPU enabled" flag and arrange for
> > a signal delivery (SIGSEGV in this case).
> > 
> > Fixed by moving the handling of type 3 into the common part of
> > do_entIF(), before we check for kernel vs. user mode.
> > 
> > Incidentally, check for kernel mode is unidiomatic; the normal
> > way to do that is !user_mode(regs).  The difference is that
> > the open-coded variant treats any of bits 63..3 of regs->ps being
> > set as "it's user mode" while the normal approach is to check just
> > the bit 3.  PS is a 4-bit register and regs->ps always will have
> > bits 63..4 clear, so the open-code variant here is actually equivalent
> > to !user_mode(regs).  Harder to follow, though...
> > 
> > Reproducer above will crash any box where CLRFEN is not ignored by
> > PAL (== any actual hardware, AFAICS; PAL used in qemu doesn't
> > bother implementing that crap).
> 
> I didn't realize I'd forgotten this in qemu.  Anyway,
> 
> Reviewed-by: Richard Henderson <rth@twiddle.net>

Not sure it's worth bothering with in palcode-clipper - for Linux it's
useless (run out of timeslice and FEN will end up set, no matter what),
nothing in NetBSD or OpenBSD trees generates that call_pal, current
FreeBSD doesn't support alpha and their last version to do so hadn't
generated that call_pal either...  What else is out there?  OSF?

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: [PATCH] alpha: fix FEN fault handling
  2023-01-07  2:46   ` Al Viro
@ 2023-01-07 21:28     ` Al Viro
  2023-01-07 23:03       ` Richard Henderson
  0 siblings, 1 reply; 5+ messages in thread
From: Al Viro @ 2023-01-07 21:28 UTC (permalink / raw)
  To: Richard Henderson; +Cc: linux-alpha, linux-kernel

On Sat, Jan 07, 2023 at 02:46:26AM +0000, Al Viro wrote:

> Not sure it's worth bothering with in palcode-clipper - for Linux it's
> useless (run out of timeslice and FEN will end up set, no matter what),
> nothing in NetBSD or OpenBSD trees generates that call_pal, current
> FreeBSD doesn't support alpha and their last version to do so hadn't
> generated that call_pal either...  What else is out there?  OSF?

BTW, out of curiosity - what was
              case 5: /* illoc */
              default: /* unexpected instruction-fault type */
about in that switch in do_entIF()?

All documentation I'd been able to find had only 0..4 as expected
values (bpt/bugcheck/gentrap/fen/opdec)...

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: [PATCH] alpha: fix FEN fault handling
  2023-01-07 21:28     ` Al Viro
@ 2023-01-07 23:03       ` Richard Henderson
  0 siblings, 0 replies; 5+ messages in thread
From: Richard Henderson @ 2023-01-07 23:03 UTC (permalink / raw)
  To: Al Viro; +Cc: linux-alpha, linux-kernel

On 1/7/23 13:28, Al Viro wrote:
> On Sat, Jan 07, 2023 at 02:46:26AM +0000, Al Viro wrote:
> 
>> Not sure it's worth bothering with in palcode-clipper - for Linux it's
>> useless (run out of timeslice and FEN will end up set, no matter what),
>> nothing in NetBSD or OpenBSD trees generates that call_pal, current
>> FreeBSD doesn't support alpha and their last version to do so hadn't
>> generated that call_pal either...  What else is out there?  OSF?
> 
> BTW, out of curiosity - what was
>                case 5: /* illoc */
>                default: /* unexpected instruction-fault type */
> about in that switch in do_entIF()?
> 
> All documentation I'd been able to find had only 0..4 as expected
> values (bpt/bugcheck/gentrap/fen/opdec)...

No idea.

Historical git (cd52cb6178a7, v2.4.8 -> v2.4.8.1) suggests it's related to shark_mv, so 
perhaps a later revision of DEC PALcode.  But I have no corresponding documentation.


r~

^ permalink raw reply	[flat|nested] 5+ messages in thread

end of thread, other threads:[~2023-01-07 23:03 UTC | newest]

Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2023-01-07  0:59 [PATCH] alpha: fix FEN fault handling Al Viro
2023-01-07  1:55 ` Richard Henderson
2023-01-07  2:46   ` Al Viro
2023-01-07 21:28     ` Al Viro
2023-01-07 23:03       ` Richard Henderson

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.