linux-um archives
 help / color / mirror / Atom feed
From: BlaisorBlade <blaisorblade_spam@yahoo.it>
To: user-mode-linux-devel@lists.sourceforge.net
Cc: Henrik Nordstrom <hno@marasystems.com>
Subject: Re: [uml-devel] /dev/kmem panic in SKAS mode
Date: Thu, 18 Mar 2004 20:17:52 +0100	[thread overview]
Message-ID: <200403182017.52188.blaisorblade_spam@yahoo.it> (raw)
In-Reply-To: <Pine.LNX.4.44.0403161053200.23697-100000@filer.marasystems.com>

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

  reply	other threads:[~2004-03-18 19:11 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-03-16 10:38 [uml-devel] /dev/kmem panic in SKAS mode Henrik Nordstrom
2004-03-18 19:17 ` BlaisorBlade [this message]
2004-03-18 23:37   ` Henrik Nordstrom
2004-03-20 16:06     ` BlaisorBlade

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=200403182017.52188.blaisorblade_spam@yahoo.it \
    --to=blaisorblade_spam@yahoo.it \
    --cc=hno@marasystems.com \
    --cc=user-mode-linux-devel@lists.sourceforge.net \
    /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