[uml-devel] /dev/kmem panic in SKAS mode

[uml-devel] /dev/kmem panic in SKAS mode

[Henrik Nordstrom]

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



-------------------------------------------------------
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=1470&alloc_id=3638&op=click
_______________________________________________
User-mode-linux-devel mailing list
User-mode-linux-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel

Re: [uml-devel] /dev/kmem panic in SKAS mode

[BlaisorBlade]

Alle 11:38, martedì 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 
applied the patch we discussed after the release (but I'm almost sure this is 
not the case).

At least, search the archives since I and Jeff discussed it (search for 
"[PATCH] fix writing into /dev/kmem" and my answers; the patch in the 1st 
message is wrong).

We understood that copy_from_user should check also for invalid addresses in 
kernel space (the i386/anything one does this check implicitly, the TT mode 
too). In skas mode he cannot rely on SIGSEGV so it checks pagetables by hand, 
but not for the kernel. In the case below it's copy_to_user that does not 
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 
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 Jeff 
made that device like /dev/mem; however this was removed when the fix above 
came in.

> 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
>
>
>
> -------------------------------------------------------
> 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=1470&alloc_id=3638&op=click
> _______________________________________________
> User-mode-linux-devel mailing list
> User-mode-linux-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel

-- 
Paolo Giarrusso, aka Blaisorblade
Linux registered user n. 292729



-------------------------------------------------------
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\x1470&alloc_id638&opÌk
_______________________________________________
User-mode-linux-devel mailing list
User-mode-linux-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel

Re: [uml-devel] /dev/kmem panic in SKAS mode

[Henrik Nordstrom]

On Thu, 18 Mar 2004, BlaisorBlade wrote:

> Alle 11:38, martedì 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 
> applied the patch we discussed after the release (but I'm almost sure this is 
> not the case).

Silly me forgot to mention what UML kernel I am using. Due to various 
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 
> "[PATCH] fix writing into /dev/kmem" and my answers; the patch in the 1st 
> 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 addresses in 
> kernel space (the i386/anything one does this check implicitly, the TT mode 
> too). In skas mode he cannot rely on SIGSEGV so it checks pagetables by hand, 
> but not for the kernel. In the case below it's copy_to_user that does not 
> 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 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?

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\x1470&alloc_id638&opÌk
_______________________________________________
User-mode-linux-devel mailing list
User-mode-linux-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel

Re: [uml-devel] /dev/kmem panic in SKAS mode

[BlaisorBlade]

Alle 00:37, venerdì 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 
applies to both  - anyway he'll have a better answer.

About this, there was also the need for a patch to mainline (mentioned in the 
same thread); I sent it to LKML and Andrew Morton, but only for 2.6 (it has 
been corrected a lot by Andrew Morton and sent to Linus for inclusion); 2.4 
still lacks the fix (as of 2.4.25).

-- 
Paolo Giarrusso, aka Blaisorblade
Linux registered user n. 292729



-------------------------------------------------------
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\x1470&alloc_id638&opÌk
_______________________________________________
User-mode-linux-devel mailing list
User-mode-linux-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel