From: Henrik N. <hn...@ma...> - 2004-03-16 10:38:13
|
There seems to be some kind of vm addressing related issue in SKAS mode. This time related to reading of /dev/kmem. The following kernel panic is seen when klogd starts up: #0 panic (fmt=0xa014ce00 "Kernel mode fault at addr 0x%lx, ip 0x%lx") at panic.c:60 #1 0xa006fab6 in segv (address=1116127232, ip=1074706056, is_write=0, is_user=0, sc=0xa13c8274) at trap_kern.c:149 #2 0xa006feaa in segv_handler (sig=11, regs=0xa13c8274) at trap_user.c:67 #3 0xa007615d in sig_handler_common_skas (sig=11, sc_ptr=0x58) at trap_user.c:35 #4 0xa006ff99 in sig_handler (sig=0, sc= {gs = 0, __gsh = 0, fs = 0, __fsh = 0, es = 123, __esh = 0, ds = 123, __dsh = 0, edi = 2705474036, esi = 1116127232, ebp = 2705111756, esp = 2705111748, ebx = 2685835552, edx = 2705111928, ecx = 15, eax = 60, trapno = 14, err = 4, eip = 2684838993, cs = 115, __csh = 0, eflags = 66054, esp_at_signal = 2705111748, ss = 123, __ssh = 0, fpstate = 0x0, oldmask = 0, cr2 = 1116127232}) at trap_user.c:103 #5 <signal handler called> #6 0xa0076451 in copy_chunk_to_user (to=2705474036, len=60, arg=0xa13cbb78) at string.h:202 #7 0xa00762ca in do_op (addr=2705474036, len=60, is_write=1, op=0xa007643c <copy_chunk_to_user>, arg=0xa13cbb78) at uaccess.c:46 #8 0xa007630d in buffer_op (addr=134541812, len=-1589855368, is_write=1, op=0xa007643c <copy_chunk_to_user>, arg=0xa13cbb78) at uaccess.c:59 #9 0xa00764b8 in copy_to_user_skas (to=0x804f1f4, from=0x4286c000, n=-1589855368) at uaccess.c:122 #10 0xa0079851 in read_kmem (file=0xa13ae1e4, buf=0x804f1f4 <Address 0x804f1f4 out of bounds>, count=60, ppos=0xa13ae204) at mem.c:264 #11 0xa0032d41 in sys_read (fd=60, buf=0x804f1f4 <Address 0x804f1f4 out of bounds>, count=60) at read_write.c:177 #12 0xa0075c63 in execute_syscall_skas (r=0xa13cbc3c) at syscall_kern.c:28 #13 0xa0075cd8 in handle_syscall (regs=0xa13c8274) at syscall_user.c:26 #14 0xa0074e84 in handle_trap (pid=8470, regs=0xa13c8274) at process.c:85 #15 0xa0075140 in userspace (regs=0xa13c8274) at process.c:160 #16 0xa00758fa in fork_handler (sig=10) at process_kern.c:102 #17 <signal handler called> #18 0xa00ff3ed in syscall () at string.h:486 Previous frame inner to this frame (corrupt stack?) (gdb) frame 1 (gdb) p/x address $2 = 0x4286c000 (gdb) frame 10 (gdb) p/x *ppos $3 = 0xa286c000 In TT mode on the same host this problem is not seen. Host OS: Fedora Core 2 test 1 Host kernel: Fedora kernel-2.6.3-1.118 + host-skas3-2.6.3-v1.patch Regards Henrik |
From: BlaisorBlade <bla...@ya...> - 2004-03-18 19:11:06
|
Alle 11:38, marted=EC 16 marzo 2004, Henrik Nordstrom ha scritto: > There seems to be some kind of vm addressing related issue in SKAS mode. > This time related to reading of /dev/kmem. If you are not using 2.6.4, do it and it should disappear. If not, probably= he=20 applied the patch we discussed after the release (but I'm almost sure this = is=20 not the case). At least, search the archives since I and Jeff discussed it (search for=20 "[PATCH] fix writing into /dev/kmem" and my answers; the patch in the 1st=20 message is wrong). We understood that copy_from_user should check also for invalid addresses i= n=20 kernel space (the i386/anything one does this check implicitly, the TT mode= =20 too). In skas mode he cannot rely on SIGSEGV so it checks pagetables by han= d,=20 but not for the kernel. In the case below it's copy_to_user that does not=20 check the from address, but it's the same anyway. Now, to do this, he set fault_catcher for this case so the SIGSEGV for the= =20 case below will be handled in the same way as for TT. The problem actually is because to workaround the panic on cat /dev/kmem Je= ff=20 made that device like /dev/mem; however this was removed when the fix above= =20 came in. > The following kernel panic is seen when klogd starts up: > > #0 panic (fmt=3D0xa014ce00 "Kernel mode fault at addr 0x%lx, ip 0x%lx") = at > panic.c:60 > #1 0xa006fab6 in segv (address=3D1116127232, ip=3D1074706056, is_write= =3D0, > is_user=3D0, sc=3D0xa13c8274) at trap_kern.c:149 > #2 0xa006feaa in segv_handler (sig=3D11, regs=3D0xa13c8274) at trap_user= =2Ec:67 > #3 0xa007615d in sig_handler_common_skas (sig=3D11, sc_ptr=3D0x58) at > trap_user.c:35 > #4 0xa006ff99 in sig_handler (sig=3D0, sc=3D {gs =3D 0, __gsh =3D 0, fs = =3D 0, __fsh > =3D 0, es =3D 123, __esh =3D 0, ds =3D 123, __dsh =3D 0, edi =3D 27054740= 36, esi =3D > 1116127232, ebp =3D 2705111756, esp =3D 2705111748, ebx =3D 2685835552, e= dx =3D > 2705111928, ecx =3D 15, eax =3D 60, trapno =3D 14, err =3D 4, eip =3D 268= 4838993, cs > =3D 115, __csh =3D 0, eflags =3D 66054, esp_at_signal =3D 2705111748, ss = =3D 123, > __ssh =3D 0, fpstate =3D 0x0, oldmask =3D 0, cr2 =3D 1116127232}) at > trap_user.c:103 #5 <signal handler called> > #6 0xa0076451 in copy_chunk_to_user (to=3D2705474036, len=3D60, > arg=3D0xa13cbb78) at string.h:202 #7 0xa00762ca in do_op (addr=3D2705474= 036, > len=3D60, is_write=3D1, op=3D0xa007643c <copy_chunk_to_user>, arg=3D0xa13= cbb78) at > uaccess.c:46 #8 0xa007630d in buffer_op (addr=3D134541812, len=3D-158985= 5368, > is_write=3D1, op=3D0xa007643c <copy_chunk_to_user>, arg=3D0xa13cbb78) at > uaccess.c:59 #9 0xa00764b8 in copy_to_user_skas (to=3D0x804f1f4, > from=3D0x4286c000, n=3D-1589855368) at uaccess.c:122 #10 0xa0079851 in > read_kmem (file=3D0xa13ae1e4, buf=3D0x804f1f4 <Address 0x804f1f4 out of > bounds>, count=3D60, ppos=3D0xa13ae204) at mem.c:264 #11 0xa0032d41 in sy= s_read > (fd=3D60, buf=3D0x804f1f4 <Address 0x804f1f4 out of bounds>, count=3D60) = at > read_write.c:177 #12 0xa0075c63 in execute_syscall_skas (r=3D0xa13cbc3c) = at > syscall_kern.c:28 #13 0xa0075cd8 in handle_syscall (regs=3D0xa13c8274) at > syscall_user.c:26 #14 0xa0074e84 in handle_trap (pid=3D8470, regs=3D0xa13= c8274) > at process.c:85 #15 0xa0075140 in userspace (regs=3D0xa13c8274) at > process.c:160 > #16 0xa00758fa in fork_handler (sig=3D10) at process_kern.c:102 > #17 <signal handler called> > #18 0xa00ff3ed in syscall () at string.h:486 > Previous frame inner to this frame (corrupt stack?) > > (gdb) frame 1 > (gdb) p/x address > $2 =3D 0x4286c000 > > (gdb) frame 10 > (gdb) p/x *ppos > $3 =3D 0xa286c000 > > > In TT mode on the same host this problem is not seen. > > Host OS: Fedora Core 2 test 1 > Host kernel: Fedora kernel-2.6.3-1.118 + host-skas3-2.6.3-v1.patch > > > Regards > Henrik > > > > ------------------------------------------------------- > This SF.Net email is sponsored by: IBM Linux Tutorials > Free Linux tutorial presented by Daniel Robbins, President and CEO of > GenToo technologies. Learn everything from fundamentals to system > administration.http://ads.osdn.com/?ad_id=3D1470&alloc_id=3D3638&op=3Dcli= ck > _______________________________________________ > User-mode-linux-devel mailing list > Use...@li... > https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel =2D-=20 Paolo Giarrusso, aka Blaisorblade Linux registered user n. 292729 |
From: Henrik N. <hn...@ma...> - 2004-03-18 23:37:41
|
On Thu, 18 Mar 2004, BlaisorBlade wrote: > Alle 11:38, marted=EC 16 marzo 2004, Henrik Nordstrom ha scritto: > > There seems to be some kind of vm addressing related issue in SKAS mo= de. > > This time related to reading of /dev/kmem. >=20 > If you are not using 2.6.4, do it and it should disappear. If not, prob= ably he=20 > applied the patch we discussed after the release (but I'm almost sure t= his is=20 > not the case). Silly me forgot to mention what UML kernel I am using. Due to various=20 reasons I have to stick to a 2.4 UML kernel. UML Kernel: 2.4.25 UML patch: Current CVS > At least, search the archives since I and Jeff discussed it (search for= =20 > "[PATCH] fix writing into /dev/kmem" and my answers; the patch in the 1= st=20 > message is wrong). Found the thread, but not sure what needs to be changed. On the 4/3 Jeff mentioned the fault_catcher and some wrapping of the guts in copy_user to fix this problem, but no code ;-) > We understood that copy_from_user should check also for invalid address= es in=20 > kernel space (the i386/anything one does this check implicitly, the TT = mode=20 > too). In skas mode he cannot rely on SIGSEGV so it checks pagetables by= hand,=20 > but not for the kernel. In the case below it's copy_to_user that does n= ot=20 > check the from address, but it's the same anyway. Sounds promising. Anyway, for now I can live without klogd in this environment, but it woul= d be nice to have this issue fixed. Is this problem planned to be fixed in the 2.4 tree, or only the 2.6 tree? Regards Henrik |
From: BlaisorBlade <bla...@ya...> - 2004-03-20 15:59:10
|
Alle 00:37, venerd=EC 19 marzo 2004, Henrik Nordstrom ha scritto: > On Thu, 18 Mar 2004, BlaisorBlade wrote: [... about the /dev/kmem - copy_to_user fix ] > Found the thread, but not sure what needs to be changed. On the 4/3 Jeff > mentioned the fault_catcher and some wrapping of the guts in copy_user to > fix this problem, but no code ;-) > Anyway, for now I can live without klogd in this environment, but it would > be nice to have this issue fixed. Is this problem planned to be fixed in > the 2.4 tree, or only the 2.6 tree? I think Jeff just didn't yet release a new 2.4 patch, since the reasoning=20 applies to both - anyway he'll have a better answer. About this, there was also the need for a patch to mainline (mentioned in t= he=20 same thread); I sent it to LKML and Andrew Morton, but only for 2.6 (it has= =20 been corrected a lot by Andrew Morton and sent to Linus for inclusion); 2.4= =20 still lacks the fix (as of 2.4.25). =2D-=20 Paolo Giarrusso, aka Blaisorblade Linux registered user n. 292729 |