Non-fatal oops on SGI IP22 when doing: md5sum /dev/mem

Non-fatal oops on SGI IP22 when doing: md5sum /dev/mem

[Martin Michlmayr]

I get the following non-fatal oops on SGI IP22 (2.6.16-rc5) when
running "md5sum /dev/mem".  I know it's not very smart to run this
command but nevertheless we shouldn't oops.  FWIW, i386 reports
"md5sum: /dev/mem: Bad address".


sgi:/# md5sum /dev/mem
Segmentation fault

MC Bus Error
GIO error 0x400:<TIME > @ 0x00090000
Data bus error, epc == ffffffff881b0cf0, ra == ffffffff881c9ab4
Oops[#8]:
Cpu 0
$ 0   : 0000000000000000 0000000000000004 ffffffff80090000 0000000000000000
$ 4   : 00000000100023a8 ffffffff80090000 0000000000001000 ffffffff8a6dfe88
$ 8   : 0000000000000040 0000000000000000 0000000000000000 0000000000008000
$12   : 0000000000000008 0000000000008000 0000000000001000 ffffffffb0000000
$16   : 0000000000000000 00000000100033a8 ffffffff80000000 ffffffff8a6dfe88
$20   : 0000000000008000 ffffffffffffffff 000000007fcf29a8 00000000100022e8
$24   : 0000000000000000 0000000000090000                                  
$28   : ffffffff8a6dc000 ffffffff8a6dfe30 0000000000008000 ffffffff881c9ab4
Hi    : 0000000000000000
Lo    : 0000000000000000
epc   : ffffffff881b0cf0 both_aligned+0x10/0x64     Not tainted
ra    : ffffffff881c9ab4 read_mem+0xec/0x138
Status: 3004cce3    KX SX UX KERNEL EXL IE 
Cause : 1000401c
PrId  : 00000460
Modules linked in: md5 ipv6
Process md5sum (pid: 1211, threadinfo=ffffffff8a6dc000, task=ffffffff8c0e0128)
Stack : ffffffff8c1c5aa0 0000000000000000 00000000100023a8 ffffffff880902bc
        fffffffffffffff7 00000000100023a8 ffffffff8c1c5aa0 00000000100022e8
        ffffffffffffffff ffffffff88091014 0000000000000000 0000000000090000
        0000000000000000 0000000000008000 000000007fcf2998 ffffffff8801de8c
        0000000000000000 0000000000000004 0000000000000fa3 0000000000008000
        0000000000000003 00000000100023a8 0000000000008000 0000000000000000
        0000000000000000 ffffffffb0000000 0000000000000000 ffffffffffffff0f
        0000000000000000 0000000000000000 0000000000000000 ffffffffff000000
        0000000000000000 0000000000000000 0000000000000000 ffffffffb0000000
        0000000000000000 0000000000000000 000000006f857da9 ffffffffa9c7a710
        ...
Call Trace:
 [<ffffffff880902bc>] vfs_read+0xfc/0x1b8
 [<ffffffff88091014>] sys_read+0x4c/0x90
 [<ffffffff8801de8c>] handle_sys+0x12c/0x148


Code: 11000017  30d8003f  00000000 <dca80000> dca90008  dcaa0010  dcab0018  64c6ffc0  dcac0020 

-- 
Martin Michlmayr
http://www.cyrius.com/

Non-fatal oops on SGI IP22 when doing: md5sum /dev/core

[Martin Michlmayr]

I get the (different) non-fatal oopses on SGI IP22 (2.6.16-rc5) when
running "md5sum /dev/core".  Two exampls are attached below.  FWIW,
this works on i386.


sgi:/# md5sum /dev/core
Segmentation fault

MC Bus Error
GIO error 0x400:<TIME > @ 0x00090000
Data bus error, epc == ffffffff881b0cf0, ra == ffffffff880e06c0
Oops[#10]:
Cpu 0
$ 0   : 0000000000000000 0000000000000004 0000000000001000 0000000000000000
$ 4   : 00000000100033a8 ffffffff80090000 0000000000001000 0000000000091000
$ 8   : 0000000000000040 0000000000000000 0000000000000000 00000000000000b0
$12   : 00000000000000b0 00000000100043a8 ffffffff88090fc8 00000000000000b0
$16   : 0000000000001000 ffffffff80090000 0000000000001000 ffffffff8a6dfe88
$20   : 0000000000007000 0000000000001000 ffffffff8a6dfe88 00000000100033a8
$24   : 0000000000000000 000000002abd5ca0                                  
$28   : ffffffff8a6dc000 ffffffff8a6dfb20 ffffffff88430000 ffffffff880e06c0
Hi    : 0000000000000000
Lo    : 0000000000000150
epc   : ffffffff881b0cf0 both_aligned+0x10/0x64     Not tainted
ra    : ffffffff880e06c0 read_kcore+0x220/0x7a0
Status: 3004cce3    KX SX UX KERNEL EXL IE 
Cause : 1000401c
PrId  : 00000460
Modules linked in: md5 ipv6
Process md5sum (pid: 1213, threadinfo=ffffffff8a6dc000, task=ffffffff8c0e0d58)
Stack : ffffffff8831a898 00000001000001e0 ffffffff8a6dfbf0 ffffffff8831a898
        0000000300000088 ffffffff8a6dfb68 ffffffff8831a898 0000000400000618
        ffffffff8c0e0d58 0052000000000000 0000000000000000 0000000000000000
        0000000000000000 0000000000000000 766d6c696e757800 0000000000000000
        726f6f743d2f6465 762f736461310000 0000000000000000 0000000000000000
        0000000000000000 0000000000000000 0000000000000000 0000000000000000
        0000000000000000 0000000000000000 0000000000000000 0000000000000000
        0000000000000000 0000000000000000 0000000000000000 0000000000000000
        0000000000000000 0000000000000000 0000000000000000 0000000000000000
        0000000000000000 0000000000000000 0000000000000000 0000000000000000
        ...
Call Trace:
 [<ffffffff88183c90>] avc_has_perm+0x68/0x98
 [<ffffffff88183f70>] inode_has_perm+0x50/0xb8
 [<ffffffff88041138>] getnstimeofday+0x18/0x50
 [<ffffffff88058cf8>] ktime_get_ts+0x60/0xb8
 [<ffffffff881840b8>] file_has_perm+0xe0/0x108
 [<ffffffff881ea24c>] i8042_interrupt+0x64/0x4e8
 [<ffffffff880902bc>] vfs_read+0xfc/0x1b8
 [<ffffffff88091014>] sys_read+0x4c/0x90
 [<ffffffff8801de8c>] handle_sys+0x12c/0x148


sgi:/# md5sum /dev/core
Segmentation fault

Code: 11000017  30d8003f  00000000 <dca80000> dca90008  dcaa0010  dcab0018  64c6ffc0  dcac0020 
MC Bus Error
GIO error 0x400:<TIME > @ 0x00090000
Data bus error, epc == ffffffff881b0cf0, ra == ffffffff880e06c0
Oops[#11]:
Cpu 0
$ 0   : 0000000000000000 0000000000000004 0000000000001000 0000000000000000
$ 4   : 00000000100033a8 ffffffff80090000 0000000000001000 0000000000091000
$ 8   : 0000000000000040 0000000000000000 0000000000000000 00000000000000b0
$12   : 00000000000000b0 00000000100043a8 ffffffff88090fc8 00000000000000b0
$16   : 0000000000001000 ffffffff80090000 0000000000001000 ffffffff8a6dfe88
$20   : 0000000000007000 0000000000001000 ffffffff8a6dfe88 00000000100033a8
$24   : 0000000000000000 000000002abd5ca0                                  
$28   : ffffffff8a6dc000 ffffffff8a6dfb20 ffffffff88430000 ffffffff880e06c0
Hi    : 0000000000000000
Lo    : 0000000000000150
epc   : ffffffff881b0cf0 both_aligned+0x10/0x64     Not tainted
ra    : ffffffff880e06c0 read_kcore+0x220/0x7a0
Status: 1004cce3    KX SX UX KERNEL EXL IE 
Cause : 1000401c
PrId  : 00000460
Modules linked in: md5 ipv6
Process md5sum (pid: 1214, threadinfo=ffffffff8a6dc000, task=ffffffff8c0e0d58)
Stack : ffffffff88041ccc ffffffff88420000 0000000000000000 ffffffff884250b8
        000000000000000a ffffffff88420000 ffffffff88041e0c 0000000000000000
        000000003004cce0 0000000000000000 0000000000000001 0000000000000003
        0000000000000002 ffffffff8a6dfdc0 0000000000000002 ffffffff88041f88
        0000000000008000 ffffffff88005ab8 0000000000000000 0000000000000004
        0000000000000000 ffffffff884344f0 0000000000000001 0000000000000003
        0000000000000006 0000000000000002 0000000000000000 0000000000000000
        0000000000000000 0000000000008000 0000000000000008 ffffffff881b1848
        ffffffff88090fc8 000000000000b0df 0000000000000006 0000000000000000
        0000000000000001 0000000000000003 0000000000000002 ffffffff8a6dfdc0
        ...
Call Trace:
 [<ffffffff88041ccc>] tasklet_action+0xc4/0x140
 [<ffffffff88041e0c>] __do_softirq+0xc4/0x1a0
 [<ffffffff88041f88>] do_softirq+0xa0/0xd0
 [<ffffffff88005ab8>] indyIRQ+0x118/0x180
 [<ffffffff881b1848>] memset_partial+0x44/0x60
 [<ffffffff88090fc8>] sys_read+0x0/0x90
 [<ffffffff88183c90>] avc_has_perm+0x68/0x98
 [<ffffffff88183f70>] inode_has_perm+0x50/0xb8
 [<ffffffff88041138>] getnstimeofday+0x18/0x50
 [<ffffffff88058cf8>] ktime_get_ts+0x60/0xb8
 [<ffffffff881840b8>] file_has_perm+0xe0/0x108
 [<ffffffff881ea24c>] i8042_interrupt+0x64/0x4e8
 [<ffffffff880902bc>] vfs_read+0xfc/0x1b8
 [<ffffffff88091014>] sys_read+0x4c/0x90
 [<ffffffff8801de8c>] handle_sys+0x12c/0x148


Code: 11000017  30d8003f  00000000 <dca80000> dca90008  dcaa0010  dcab0018  64c6ffc0  dcac0020 

-- 
Martin Michlmayr
http://www.cyrius.com/

Re: Non-fatal oops on SGI IP22 when doing: md5sum /dev/mem

[Martin Michlmayr]

* Martin Michlmayr <tbm@cyrius.com> [2006-02-28 11:41]:
> I get the following non-fatal oops on SGI IP22 (2.6.16-rc5) when
> running "md5sum /dev/mem".  I know it's not very smart to run this
> command but nevertheless we shouldn't oops.  FWIW, i386 reports
> "md5sum: /dev/mem: Bad address".

Right, so we had a fun discussion about this on IRC today... The
bottom line is that the kernel cannot to anything about it and root
should know what they're doing.


12:39 < ladis> tbm: you cannot read from /dev/mem randomly ;-)
12:46 < tbm> ladis: yeah, but my point is that it shouldn't oops/segfault
12:48 < ladis> tbm: Well, you acessed GIO space and MC asserted BERR interrupt. That's pretty valid behaviour.
12:50 < tbm> ladis: a oops and segfault doesn't seem like valid behaviour from the perspective of an end user.  Why cannot it catch such an access and return "Bad address" like i386 does
12:51 < p2-mate> tbm: if you do hw access in userland, you're on your own :)
12:53 < tbm> p2-mate: I still maintain that an oops is not an acceptable behaviour from a user POV
12:56 < Bacchus> tbm: I'm missing some context here - what is oopsing?
12:57 < p2-mate> tbm: rm /dev/mem
12:57 < p2-mate> tbm: problem solved :)
12:57 < tbm> p2-mate: so why does /dev/mem exist in the first place...
12:57 < tbm> Bacchus: print a traceback
12:57 < p2-mate> tbm: otherwise the X server does not work
12:58 < Bacchus> tbm: Doesn't work very well but I've never seen a traceback oopsing.
12:59 < tbm> well, isn't this thing called an oops?  Or what's the right terminiology?
12:59 < tbm> Data bus error, epc == ffffffff881b0cf0, ra == ffffffff881c9ab4
12:59 < tbm> Oops[#8]:
12:59 < tbm> Cpu 0
12:59 < tbm> $ 0   : 0000000000000000 0000000000000004 ffffffff80090000 0000000000000000
12:59 < tbm> $ 4   : 00000000100023a8 ffffffff80090000 0000000000001000 ffffffff8a6dfe88
12:59 < tbm> ..
12:59 < tbm> Call Trace:
12:59 < tbm>  [<ffffffff880902bc>] vfs_read+0xfc/0x1b8
12:59 < tbm> ..
12:59 < ladis> p2-mate: That's problem of bloody crappy random number generator in xdm
12:59 < ladis> tbm: Right, it is Data bus error and I implemented it ;-)
12:59 < tbm> p2-mate: right, but my point is that the file is there and so it can be expected that some users try to read it
13:00 < Bacchus> Okay - and a DBE when doing what?
13:00 < tbm> so either we shouldn't ship the file, or we should handle reading from it gracefully
13:00 < p2-mate> tbm: well, perhapd it should not be there ?
13:00 < ladis> tbm: There was long debate about acesing /dev/mem on debian-mips archive few years ago
13:00 < tbm> Bacchus: doing "md5sum /dev/mem"
13:00 < ladis> tbm: search for xdm
13:00 < p2-mate> BERR is imprecise ?
13:00 < Bacchus> tbm: You're kidding?
13:00 < tbm> Bacchus: which may be a stupid thing, but still shouldn't oops and segfault
13:00 < ladis> tbm: It *will* always segfault on certain machines
13:01 < tbm> so why does i386 manage to produce a nice "Bad address" error?
13:01 < tbm> why is that not possible on mips?
13:01 < Bacchus> tbm: FOr this operation even formatting your hard disk would be ok.
13:01 < geoman> heh, I can confirm the oops on 2.6.16-rc4
13:01 < ladis> aiiie ;-)
13:01 < tbm> Bacchus: well, that's what i disagree with.  If /dev/mem is so dangerous, it shouldn't exist.
13:02 < Bacchus> Welcome to UNIX :)
13:02 < ladis> tbm: No. It is very powerfull. And only root can cope with that...
13:02 < ladis> tbm: Remember userspace drivers
13:03 < geoman> hmm, speaking of display managers and oopses
13:03 < Bacchus> tbm: /dev/mem gives free access to any and all devices in the system just like the kernel.  No safety net.
13:03 < ladis> tbm: And even removing /dev/mem doesn't prevent you from writing program that does mmap
13:03 < geoman> I seem to recall that wdm causes a non-fatal oops on ip22
13:04 < geoman> perhaps it is related
13:04 < ladis> geoman: sure it is
13:05 < ladis> display managers authors are insane i386 centric idiots thinking that reading enough /dev/mem gives you enough randomness for security purposes
13:05 < ladis> I never got this point...
13:05 < Bacchus> tbm: And yes, there are many that argue that /dev/mem should be deprecated.
13:11 < geoman> yep, wdm causes an identical oops
13:12 < tbm> ok, at least my O2 boots again
13:13 < tbm> anyway, I do agree with you that /dev/mem is dangerous and that root should know what they're doing
13:13 < tbm> however, the tiny bit I don't understand is that if the kernel manages to recognize this wrong access and issue a BERR, why cannot it simply return an error to the userland program
13:13 < tbm> but anyway, I guess there are more important things to worry about
13:14 < geoman> well, my understanding is that the kernel should never oops
13:15 < Bacchus> tbm: By the time we receive a bus error we're dead in the water.  Game over.  Tilt.  Insert coin to continue ;-)
13:18 < geoman> heh, doing "md5sum /dev/mem" on my O2 doesn't return any error at all
13:18 < geoman> I think it is really trying to take the md5sum of all that random crud ;)
13:19 < Bacchus> A bus error just doesn't have enough knowledge about what went wrong, aside of a few
                 carefully controlled scenarios like hw probing.
...
13:37 < Bacchus> geoman: So how does wdm trigger it?
13:38 < ladis> Bacchus: Read above
13:38 < ladis> Bacchus: <ladis> display managers authors are insane i386 centric idiots thinking that
               reading enough /dev/mem gives you enough randomness for security purposes
13:39 < Bacchus> ladis: Eh...  You meant you were serious?!?
13:39 < ladis> Bacchus: They are indeed doing that.
13:39 < ths> Bacchus: Sure. Wdm dies on my Indy.
13:39 < geoman> Bacchus: by simply tring to start it
13:39 < ladis> ...and the reason is above..
13:48  * Bacchus googles for wdm ...
13:50 < Bacchus> Btw, wtf does wdm work for non-root then?
13:50 < geoman> nope
13:51 < geoman> if you try to run it non-root, it returns a message that "Only root wants to run wdm"
13:55 < ladis> Bacchus: http://lists.debian.org/debian-mips/2002/08/msg00060.html
13:55 < ladis> Bacchus: That's start of pretty nice discussion. Read on your own risc ;-)

-- 
Martin Michlmayr
http://www.cyrius.com/