From: Michael Schmitz <schmitzmic@gmail.com>
To: linux-m68k@vger.kernel.org, geert@linux-m68k.org
Cc: schmitzmic@gmail.com, Finn Thain <fthain@linux-m68k.org>,
linux-m68k@lists.linux-m68k.org
Subject: [PATCH RFC] m68k: Handle __generic_copy_to_user faults more carefully
Date: Wed, 17 Apr 2024 08:36:43 +1200 [thread overview]
Message-ID: <20240416203643.3390-1-schmitzmic@gmail.com> (raw)
As mentioned by Finn Thain in his patch to improve put_user
exception handling on 040, a similar problem exists on 030
processors.
A moves instruction that crosses a page boundary from a
mapped page into an unmapped one will cause a mid-instruction
bus error exception (frame format b), with the PC pointing
two instructions past the faulting movesl instruction.
Our exception handling in __generic_copy_to_user only covers
the instruction immediately following the faulting one. As
a result, fixup_exception in send_fault_sig does not detect
this case, and cause send_fault_sig to oops.
Addition of a NOP does avert the fault in this case also.
I have tested this fault scenario with a transfer beginning
at a single byte at the end of a mapped page only, which IMO
does violate m68k alignment rules. I cannot remember ever
seeing such faults reported from conforming software before.
Fault Oops:
[3432825.940000] Unable to handle kernel access at virtual address 45e80efc
[3432826.000000] Oops: 00000000
[3432826.040000] Modules linked in: ne 8390p
[3432826.110000] PC: [<003217de>] __generic_copy_to_user+0x22/0x40
[3432826.150000] SR: 2200 SP: 3ae57f7e a2: 00781db0
[3432826.200000] d0: 00000002 d1: 00000002 d2: 2f686f6d d3: 009d7000
[3432826.250000] d4: 00000400 d5: c0014fff a0: 009d7ff6 a1: c0015003
[3432826.310000] Process badaddr (pid: 7538, task=94e249df)
[3432826.350000] Frame format=B ssw=0739 isc=6706 isb=0001 daddr=c0015000 dobuf=2f686f6d
[3432826.420000] baddr=003217d8 dibuf=2f686f6d ver=f
[3432826.460000] Stack from 00c7df88:
[3432826.460000] 0000000e 0010f1b6 c0014fff 009d7ff2 0000000e 00000400 c0014fff c0014fff
[3432826.460000] 00000400 00674cd0 00da76c0 00674cd0 0073bbd0 009d7ff2 00000ff2 effffc4c
[3432826.460000] 000026c6 c0014fff 00000400 c0014fff c0014fff 00000400 80002dec effffcec
[3432826.460000] 80002db0 000000b7 000000b7 00000000 0208c00b 91700080
[3432826.690000] Call Trace: [<0010f1b6>] sys_getcwd+0xfe/0x11c
[3432826.750000] [<000026c6>] syscall+0x8/0xc
[3432826.790000]
[3432826.830000] Code: 226f 0008 4a80 670a 2418 0e99 2800 5380 <66f6> 0801 0001 6706 3418 0e59 2800 0801 0000 6706 1418 0e19 2800 241f 4e75 2f02
Disassembly (from a different kernel image but same code, fault PC 0x1a3476 here):
001a3454 <__generic_copy_to_user>:
1a3454: 2f02 movel %d2,%sp@-
1a3456: 222f 0010 movel %sp@(16),%d1
1a345a: 2001 movel %d1,%d0
1a345c: e488 lsrl #2,%d0
1a345e: 7403 moveq #3,%d2
1a3460: c282 andl %d2,%d1
1a3462: 206f 000c moveal %sp@(12),%a0
1a3466: 226f 0008 moveal %sp@(8),%a1
1a346a: 4a80 tstl %d0
1a346c: 670a beqs 1a3478 <__generic_copy_to_user+0x24>
1a346e: 2418 movel %a0@+,%d2
1a3470: 0e99 2800 movesl %d2,%a1@+
1a3474: 5380 subql #1,%d0
1a3476: 66f6 bnes 1a346e <__generic_copy_to_user+0x1a>
1a3478: 0801 0001 btst #1,%d1
1a347c: 6706 beqs 1a3484 <__generic_copy_to_user+0x30>
1a347e: 3418 movew %a0@+,%d2
1a3480: 0e59 2800 movesw %d2,%a1@+
1a3484: 0801 0000 btst #0,%d1
1a3488: 6706 beqs 1a3490 <__generic_copy_to_user+0x3c>
1a348a: 1418 moveb %a0@+,%d2
1a348c: 0e19 2800 movesb %d2,%a1@+
1a3490: 241f movel %sp@+,%d2
1a3492: 4e75 rts
Cc: Finn Thain <fthain@linux-m68k.org>
Cc: Geert Uytterhoeven <geert@linux-m68k.org>
Cc: linux-m68k@lists.linux-m68k.org
Link: https://lore.kernel.org/all/e0f23460779e6d16e2633486ac4841790ef2aca0.1713176294.git.fthain@linux-m68k.org
Signed-off-by: Michael Schmitz <schmitzmic@gmail.com>
---
arch/m68k/lib/uaccess.c | 26 ++++++++++++++++----------
1 file changed, 16 insertions(+), 10 deletions(-)
diff --git a/arch/m68k/lib/uaccess.c b/arch/m68k/lib/uaccess.c
index 7646e461aa62..48643ef46900 100644
--- a/arch/m68k/lib/uaccess.c
+++ b/arch/m68k/lib/uaccess.c
@@ -60,20 +60,23 @@ unsigned long __generic_copy_to_user(void __user *to, const void *from,
asm volatile ("\n"
" tst.l %0\n"
- " jeq 4f\n"
+ " jeq 5f\n"
"1: move.l (%1)+,%3\n"
"2: "MOVES".l %3,(%2)+\n"
- "3: subq.l #1,%0\n"
+ "3: nop\n"
+ "4: subq.l #1,%0\n"
" jne 1b\n"
- "4: btst #1,%5\n"
- " jeq 6f\n"
- " move.w (%1)+,%3\n"
- "5: "MOVES".w %3,(%2)+\n"
- "6: btst #0,%5\n"
+ "5: btst #1,%5\n"
" jeq 8f\n"
+ " move.w (%1)+,%3\n"
+ "6: "MOVES".w %3,(%2)+\n"
+ "7: nop\n"
+ "8: btst #0,%5\n"
+ " jeq 11f\n"
" move.b (%1)+,%3\n"
- "7: "MOVES".b %3,(%2)+\n"
- "8:\n"
+ "9: "MOVES".b %3,(%2)+\n"
+ "10: nop\n"
+ "11:\n"
" .section .fixup,\"ax\"\n"
" .even\n"
"20: lsl.l #2,%0\n"
@@ -85,10 +88,13 @@ unsigned long __generic_copy_to_user(void __user *to, const void *from,
" .align 4\n"
" .long 2b,20b\n"
" .long 3b,20b\n"
- " .long 5b,50b\n"
+ " .long 4b,20b\n"
" .long 6b,50b\n"
" .long 7b,50b\n"
" .long 8b,50b\n"
+ " .long 9b,50b\n"
+ " .long 10b,50b\n"
+ " .long 11b,50b\n"
" .previous"
: "=d" (res), "+a" (from), "+a" (to), "=&d" (tmp)
: "0" (n / 4), "d" (n & 3));
--
2.17.1
next reply other threads:[~2024-04-16 20:36 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-04-16 20:36 Michael Schmitz [this message]
2024-04-17 6:59 ` [PATCH RFC] m68k: Handle __generic_copy_to_user faults more carefully Geert Uytterhoeven
2024-04-17 8:08 ` Michael Schmitz
2024-04-17 8:16 ` Eero Tamminen
2024-04-17 16:26 ` Andreas Schwab
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20240416203643.3390-1-schmitzmic@gmail.com \
--to=schmitzmic@gmail.com \
--cc=fthain@linux-m68k.org \
--cc=geert@linux-m68k.org \
--cc=linux-m68k@lists.linux-m68k.org \
--cc=linux-m68k@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
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.