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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).