Hello everyone!
I've found strange behavior of reading /dev/mem:
for i in 0 1 2; do
echo $i
dd if=/dev/mem of=/dev/null skip=$((6+$i)) bs=$((0x20000000)) count=1
done
On some systems with Supermicro X8DTU I've got several messages during
first 512Mb starting from 0xc000_0000:
"BUG: soft lockup - CPU#xx stuck for 61s!"
On other systems with the sameboard I've stuck without any errors at
last 10Mb before 0x1_0000_0000. Local APIC access?
On E5440 (Dell PowerEdge 1950) I've just got several:
APIC error on CPU3: 00(80)
APIC error on CPU3: 80(80)
...
APIC error on CPU3: 80(80)
That looks like wrong register access.
[E5530] $ cat /proc/iomem
00000000-0000ffff : reserved
00010000-0009dbff : System RAM
0009dc00-0009ffff : reserved
000c0000-000cffff : pnp 00:0e
000e0000-000fffff : reserved
00100000-bf77ffff : System RAM
00200000-006a37de : Kernel code
006a37df-0091a57f : Kernel data
00a68000-00b7cbaf : Kernel bss
bf78e000-bf78ffff : reserved
bf790000-bf79dfff : ACPI Tables
bf79e000-bf7cffff : ACPI Non-volatile Storage
bf7d0000-bf7dffff : reserved
bf7ec000-bfffffff : reserved
e0000000-efffffff : PCI MMCONFIG 0
e0000000-efffffff : reserved
e0000000-efffffff : pnp 00:0d
f9000000-f9ffffff : PCI Bus 0000:07
f9000000-f9ffffff : 0000:07:01.0
faeda000-faeda0ff : 0000:00:1f.3
faedc000-faedc3ff : 0000:00:1d.7
faedc000-faedc3ff : ehci_hcd
faede000-faede3ff : 0000:00:1a.7
faede000-faede3ff : ehci_hcd
faee0000-faee3fff : 0000:00:16.7
faee4000-faee7fff : 0000:00:16.6
faee8000-faeebfff : 0000:00:16.5
faeec000-faeeffff : 0000:00:16.4
faef0000-faef3fff : 0000:00:16.3
faef4000-faef7fff : 0000:00:16.2
faef8000-faefbfff : 0000:00:16.1
faefc000-faefffff : 0000:00:16.0
faf00000-faffffff : PCI Bus 0000:01
faf00000-faf1ffff : 0000:01:00.1
faf3c000-faf3ffff : 0000:01:00.1
faf3c000-faf3ffff : igb
faf40000-faf5ffff : 0000:01:00.1
faf40000-faf5ffff : igb
faf60000-faf7ffff : 0000:01:00.1
faf60000-faf7ffff : igb
faf80000-faf9ffff : 0000:01:00.0
fafbc000-fafbffff : 0000:01:00.0
fafbc000-fafbffff : igb
fafc0000-fafdffff : 0000:01:00.0
fafc0000-fafdffff : igb
fafe0000-faffffff : 0000:01:00.0
fafe0000-faffffff : igb
fb000000-fbefffff : PCI Bus 0000:07
fb000000-fb7fffff : 0000:07:01.0
fbefc000-fbefffff : 0000:07:01.0
fec00000-fec00fff : IOAPIC 0
fec00000-fec00fff : pnp 00:0c
fed00000-fed003ff : HPET 0
fed1c000-fed1ffff : pnp 00:01
fed1c000-fed1ffff : pnp 00:0a
fed20000-fed3ffff : pnp 00:0a
fed40000-fed8ffff : pnp 00:0a
fee00000-fee00fff : Local APIC
fee00000-fee00fff : reserved
fee00000-fee00fff : pnp 00:0c
ffc00000-ffffffff : reserved
100000000-13fffffff : System RAM
[ 0.000000] BIOS-provided physical RAM map:
[ 0.000000] BIOS-e820: 0000000000000000 - 000000000009dc00 (usable)
[ 0.000000] BIOS-e820: 000000000009dc00 - 00000000000a0000 (reserved)
[ 0.000000] BIOS-e820: 00000000000e0000 - 0000000000100000 (reserved)
[ 0.000000] BIOS-e820: 0000000000100000 - 00000000bf780000 (usable)
[ 0.000000] BIOS-e820: 00000000bf78e000 - 00000000bf790000 type 9
[ 0.000000] BIOS-e820: 00000000bf790000 - 00000000bf79e000 (ACPI data)
[ 0.000000] BIOS-e820: 00000000bf79e000 - 00000000bf7d0000 (ACPI NVS)
[ 0.000000] BIOS-e820: 00000000bf7d0000 - 00000000bf7e0000 (reserved)
[ 0.000000] BIOS-e820: 00000000bf7ec000 - 00000000c0000000 (reserved)
[ 0.000000] BIOS-e820: 00000000e0000000 - 00000000f0000000 (reserved)
[ 0.000000] BIOS-e820: 00000000fee00000 - 00000000fee01000 (reserved)
[ 0.000000] BIOS-e820: 00000000ffc00000 - 0000000100000000 (reserved)
[ 0.000000] BIOS-e820: 0000000100000000 - 0000000140000000 (usable)
[E5440] $ cat /proc/iomem
00000000-0009ffff : System RAM
00000000-00000000 : Crash kernel
000a0000-000bffff : Video RAM area
000c0000-000c7fff : Video ROM
000c9000-000c9fff : Adapter ROM
000ca000-000cfbff : Adapter ROM
000d0000-000d1dff : Adapter ROM
000d2000-000d71ff : Adapter ROM
000f0000-000fffff : System ROM
00100000-bfb4ffff : System RAM
00200000-003e1fbc : Kernel code
003e1fbd-004bafe7 : Kernel data
bfb50000-bfb65fff : reserved
bfb66000-bfb85bff : ACPI Tables
bfb85c00-bfffffff : reserved
d0000000-d7ffffff : PCI Bus #10
d0000000-d7ffffff : 0000:10:0d.0
d8000000-d80fffff : PCI Bus #0c
d8000000-d80fffff : PCI Bus #0d
d80f0000-d80fffff : 0000:0d:0e.0
d80f0000-d80fffff : megasas: LSI Logic
e0000000-efffffff : reserved
f2000000-f7ffffff : PCI Bus #04
f4000000-f7ffffff : PCI Bus #05
f4000000-f7ffffff : PCI Bus #06
f4000000-f7ffffff : PCI Bus #07
f4000000-f5ffffff : 0000:07:00.0
f4000000-f5ffffff : bnx2
f8000000-fbffffff : PCI Bus #02
f8000000-fbffffff : PCI Bus #03
f8000000-f9ffffff : 0000:03:00.0
f8000000-f9ffffff : bnx2
fc100000-fc2fffff : PCI Bus #10
fc100000-fc11ffff : 0000:10:0d.0
fc2d0000-fc2dffff : 0000:10:0d.0
fc300000-fc5fffff : PCI Bus #0c
fc400000-fc5fffff : PCI Bus #0d
fc400000-fc407fff : 0000:0d:0e.0
fc5c0000-fc5dffff : 0000:0d:0e.0
fc5c0000-fc5dffff : megasas: LSI Logic
fc600000-fc8fffff : PCI Bus #01
fc7e0000-fc7effff : 0000:01:00.0
fc7fc000-fc7fffff : 0000:01:00.0
fc800000-fc8fffff : 0000:01:00.0
fc900000-fc9003ff : 0000:00:1d.7
fc900000-fc9003ff : ehci_hcd
fe000000-ffffffff : reserved
100000000-43fffffff : System RAM
HP - ProLiant DL160G6 says:
http://www.pixsup.com/uploads/7134cd3e33.png
Rgds,
Anton
On Wed, Nov 11, 2009 at 05:36:51PM +0300, Anton D. Kachalov wrote:
> Hello everyone!
>
> I've found strange behavior of reading /dev/mem:
>
> for i in 0 1 2; do
> echo $i
> dd if=/dev/mem of=/dev/null skip=$((6+$i)) bs=$((0x20000000)) count=1
> done
>
> On some systems with Supermicro X8DTU I've got several messages during
> first 512Mb starting from 0xc000_0000:
>
> "BUG: soft lockup - CPU#xx stuck for 61s!"
>
> On other systems with the sameboard I've stuck without any errors at
> last 10Mb before 0x1_0000_0000. Local APIC access?
What is the full backtrace? And which version of kernel are you
running?
>
> On E5440 (Dell PowerEdge 1950) I've just got several:
> APIC error on CPU3: 00(80)
> APIC error on CPU3: 80(80)
> ...
> APIC error on CPU3: 80(80)
> That looks like wrong register access.
>
> [E5530] $ cat /proc/iomem
> 00000000-0000ffff : reserved
> 00010000-0009dbff : System RAM
> 0009dc00-0009ffff : reserved
> 000c0000-000cffff : pnp 00:0e
> 000e0000-000fffff : reserved
> 00100000-bf77ffff : System RAM
> 00200000-006a37de : Kernel code
> 006a37df-0091a57f : Kernel data
> 00a68000-00b7cbaf : Kernel bss
> bf78e000-bf78ffff : reserved
> bf790000-bf79dfff : ACPI Tables
> bf79e000-bf7cffff : ACPI Non-volatile Storage
> bf7d0000-bf7dffff : reserved
> bf7ec000-bfffffff : reserved
> e0000000-efffffff : PCI MMCONFIG 0
> e0000000-efffffff : reserved
> e0000000-efffffff : pnp 00:0d
> f9000000-f9ffffff : PCI Bus 0000:07
> f9000000-f9ffffff : 0000:07:01.0
> faeda000-faeda0ff : 0000:00:1f.3
> faedc000-faedc3ff : 0000:00:1d.7
> faedc000-faedc3ff : ehci_hcd
> faede000-faede3ff : 0000:00:1a.7
> faede000-faede3ff : ehci_hcd
> faee0000-faee3fff : 0000:00:16.7
> faee4000-faee7fff : 0000:00:16.6
> faee8000-faeebfff : 0000:00:16.5
> faeec000-faeeffff : 0000:00:16.4
> faef0000-faef3fff : 0000:00:16.3
> faef4000-faef7fff : 0000:00:16.2
> faef8000-faefbfff : 0000:00:16.1
> faefc000-faefffff : 0000:00:16.0
> faf00000-faffffff : PCI Bus 0000:01
> faf00000-faf1ffff : 0000:01:00.1
> faf3c000-faf3ffff : 0000:01:00.1
> faf3c000-faf3ffff : igb
> faf40000-faf5ffff : 0000:01:00.1
> faf40000-faf5ffff : igb
> faf60000-faf7ffff : 0000:01:00.1
> faf60000-faf7ffff : igb
> faf80000-faf9ffff : 0000:01:00.0
> fafbc000-fafbffff : 0000:01:00.0
> fafbc000-fafbffff : igb
> fafc0000-fafdffff : 0000:01:00.0
> fafc0000-fafdffff : igb
> fafe0000-faffffff : 0000:01:00.0
> fafe0000-faffffff : igb
> fb000000-fbefffff : PCI Bus 0000:07
> fb000000-fb7fffff : 0000:07:01.0
> fbefc000-fbefffff : 0000:07:01.0
> fec00000-fec00fff : IOAPIC 0
> fec00000-fec00fff : pnp 00:0c
> fed00000-fed003ff : HPET 0
> fed1c000-fed1ffff : pnp 00:01
> fed1c000-fed1ffff : pnp 00:0a
> fed20000-fed3ffff : pnp 00:0a
> fed40000-fed8ffff : pnp 00:0a
> fee00000-fee00fff : Local APIC
> fee00000-fee00fff : reserved
> fee00000-fee00fff : pnp 00:0c
> ffc00000-ffffffff : reserved
> 100000000-13fffffff : System RAM
>
> [ 0.000000] BIOS-provided physical RAM map:
> [ 0.000000] BIOS-e820: 0000000000000000 - 000000000009dc00 (usable)
> [ 0.000000] BIOS-e820: 000000000009dc00 - 00000000000a0000 (reserved)
> [ 0.000000] BIOS-e820: 00000000000e0000 - 0000000000100000 (reserved)
> [ 0.000000] BIOS-e820: 0000000000100000 - 00000000bf780000 (usable)
> [ 0.000000] BIOS-e820: 00000000bf78e000 - 00000000bf790000 type 9
> [ 0.000000] BIOS-e820: 00000000bf790000 - 00000000bf79e000 (ACPI data)
> [ 0.000000] BIOS-e820: 00000000bf79e000 - 00000000bf7d0000 (ACPI NVS)
> [ 0.000000] BIOS-e820: 00000000bf7d0000 - 00000000bf7e0000 (reserved)
> [ 0.000000] BIOS-e820: 00000000bf7ec000 - 00000000c0000000 (reserved)
> [ 0.000000] BIOS-e820: 00000000e0000000 - 00000000f0000000 (reserved)
> [ 0.000000] BIOS-e820: 00000000fee00000 - 00000000fee01000 (reserved)
> [ 0.000000] BIOS-e820: 00000000ffc00000 - 0000000100000000 (reserved)
> [ 0.000000] BIOS-e820: 0000000100000000 - 0000000140000000 (usable)
>
> [E5440] $ cat /proc/iomem
> 00000000-0009ffff : System RAM
> 00000000-00000000 : Crash kernel
> 000a0000-000bffff : Video RAM area
> 000c0000-000c7fff : Video ROM
> 000c9000-000c9fff : Adapter ROM
> 000ca000-000cfbff : Adapter ROM
> 000d0000-000d1dff : Adapter ROM
> 000d2000-000d71ff : Adapter ROM
> 000f0000-000fffff : System ROM
> 00100000-bfb4ffff : System RAM
> 00200000-003e1fbc : Kernel code
> 003e1fbd-004bafe7 : Kernel data
> bfb50000-bfb65fff : reserved
> bfb66000-bfb85bff : ACPI Tables
> bfb85c00-bfffffff : reserved
> d0000000-d7ffffff : PCI Bus #10
> d0000000-d7ffffff : 0000:10:0d.0
> d8000000-d80fffff : PCI Bus #0c
> d8000000-d80fffff : PCI Bus #0d
> d80f0000-d80fffff : 0000:0d:0e.0
> d80f0000-d80fffff : megasas: LSI Logic
> e0000000-efffffff : reserved
> f2000000-f7ffffff : PCI Bus #04
> f4000000-f7ffffff : PCI Bus #05
> f4000000-f7ffffff : PCI Bus #06
> f4000000-f7ffffff : PCI Bus #07
> f4000000-f5ffffff : 0000:07:00.0
> f4000000-f5ffffff : bnx2
> f8000000-fbffffff : PCI Bus #02
> f8000000-fbffffff : PCI Bus #03
> f8000000-f9ffffff : 0000:03:00.0
> f8000000-f9ffffff : bnx2
> fc100000-fc2fffff : PCI Bus #10
> fc100000-fc11ffff : 0000:10:0d.0
> fc2d0000-fc2dffff : 0000:10:0d.0
> fc300000-fc5fffff : PCI Bus #0c
> fc400000-fc5fffff : PCI Bus #0d
> fc400000-fc407fff : 0000:0d:0e.0
> fc5c0000-fc5dffff : 0000:0d:0e.0
> fc5c0000-fc5dffff : megasas: LSI Logic
> fc600000-fc8fffff : PCI Bus #01
> fc7e0000-fc7effff : 0000:01:00.0
> fc7fc000-fc7fffff : 0000:01:00.0
> fc800000-fc8fffff : 0000:01:00.0
> fc900000-fc9003ff : 0000:00:1d.7
> fc900000-fc9003ff : ehci_hcd
> fe000000-ffffffff : reserved
> 100000000-43fffffff : System RAM
>
> HP - ProLiant DL160G6 says:
> http://www.pixsup.com/uploads/7134cd3e33.png
>
> Rgds,
> Anton
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
--
Live like a child, think like the god.
On 11/11/2009 08:36 AM, Anton D. Kachalov wrote:
> Hello everyone!
>
> I've found strange behavior of reading /dev/mem:
>
> for i in 0 1 2; do
> echo $i
> dd if=/dev/mem of=/dev/null skip=$((6+$i)) bs=$((0x20000000)) count=1
> done
>
> On some systems with Supermicro X8DTU I've got several messages during
> first 512Mb starting from 0xc000_0000:
>
> "BUG: soft lockup - CPU#xx stuck for 61s!"
>
> On other systems with the sameboard I've stuck without any errors at
> last 10Mb before 0x1_0000_0000. Local APIC access?
>
> On E5440 (Dell PowerEdge 1950) I've just got several:
> APIC error on CPU3: 00(80)
> APIC error on CPU3: 80(80)
> ...
> APIC error on CPU3: 80(80)
> That looks like wrong register access.
I don't think that we prevent any access to device registers in /dev/mem
- if you read something that has side effects and something breaks, well
I guess you get to keep both pieces :-) There's a reason it's root-only..
On Wed, 11 Nov 2009, Robert Hancock wrote:
> I don't think that we prevent any access to device registers in
> /dev/mem - if you read something that has side effects and something
> breaks, well I guess you get to keep both pieces :-) There's a
> reason it's root-only..
We should. Imaging /dev/mem is one of the oldest tricks in the book of the
forensics people, they do it to live systems to help track down WTF happened
to a compromised host. This kind of crap bites them hard.
IMO: if you're going to provide /dev/mem, make it as safe as possible.
--
"One disk to rule them all, One disk to find them. One disk to bring
them all and in the darkness grind them. In the Land of Redmond
where the shadows lie." -- The Silicon Valley Tarot
Henrique Holschuh
On Thu, 12 Nov 2009 00:12:09 -0200
Henrique de Moraes Holschuh <[email protected]> wrote:
> On Wed, 11 Nov 2009, Robert Hancock wrote:
> > I don't think that we prevent any access to device registers in
> > /dev/mem - if you read something that has side effects and something
> > breaks, well I guess you get to keep both pieces :-) There's a
> > reason it's root-only..
>
> We should. Imaging /dev/mem is one of the oldest tricks in the book of the
> forensics people, they do it to live systems to help track down WTF happened
> to a compromised host. This kind of crap bites them hard.
Any forensics person who images /dev/mem needs to go back to school.
Alan
Am?rico Wang wrote:
> On Wed, Nov 11, 2009 at 05:36:51PM +0300, Anton D. Kachalov wrote:
>
>> Hello everyone!
>>
>> I've found strange behavior of reading /dev/mem:
>>
>> for i in 0 1 2; do
>> echo $i
>> dd if=/dev/mem of=/dev/null skip=$((6+$i)) bs=$((0x20000000)) count=1
>> done
>>
>> On some systems with Supermicro X8DTU I've got several messages during
>> first 512Mb starting from 0xc000_0000:
>>
>> "BUG: soft lockup - CPU#xx stuck for 61s!"
>>
>> On other systems with the sameboard I've stuck without any errors at
>> last 10Mb before 0x1_0000_0000. Local APIC access?
>>
>
>
> What is the full backtrace? And which version of kernel are you
> running?
>
>
Ubuntu 2.6.28-16-server and 2.6.31-11-server.
Nov 10 17:59:10 localhost kernel: [ 243.749254] BUG: soft lockup -
CPU#11 stuck for 61s! [dd:4325]
Nov 10 17:59:10 localhost kernel: [ 243.749256] Modules linked in:
ip_queue ipt_LOG xt_limit ipt_REJECT nf_conntrack_ipv4 nf_defrag_ipv4
xt_state xt_tcpudp x
t_multiport xt_NOTRACK nf_conntrack iptable_raw video output
iptable_filter ip_tables x_tables dummy parport_pc lp parport igb dca
snd_pcm serio_raw snd_timer snd soundcore snd_page_alloc iTCO_wdt
iTCO_vendor_support shpchp pcspkr raid10 raid456 raid6_pq async_xor
async_memcpy async_tx xor raid1 raid0 multipath linear fbcon tileblit
font bitblit softcursor
Nov 10 17:59:10 localhost kernel: [ 243.749282] CPU 11:
Nov 10 17:59:10 localhost kernel: [ 243.749284] Modules linked in:
ip_queue ipt_LOG xt_limit ipt_REJECT nf_conntrack_ipv4 nf_defrag_ipv4
xt_state xt_tcpudp xt_multiport xt_NOTRACK nf_conntrack iptable_raw
video output iptable_filter ip_tables x_tables dummy parport_pc lp
parport igb dca snd_pcm serio_raw snd_timer snd soundcore snd_page_alloc
iTCO_wdt iTCO_vendor_support shpchp pcspkr raid10 raid456 raid6_pq
async_xor async_memcpy async_tx xor raid1 raid0 multipath linear fbcon
tileblit font bitblit softcursor
Nov 10 17:59:10 localhost kernel: [ 243.749305] Pid: 4325, comm: dd Not
tainted 2.6.31-11-server #36ya3 X8DTU
Nov 10 17:59:10 localhost kernel: [ 243.749307] RIP:
0010:[<ffffffff81061fd5>] [<ffffffff81061fd5>] r_next+0x5/0x30
Nov 10 17:59:10 localhost kernel: [ 243.749316] RSP:
0018:ffff88012b55fe48 EFLAGS: 00000206
Nov 10 17:59:10 localhost kernel: [ 243.749317] RAX: ffff8800280211e0
RBX: ffff88012b55fe88 RCX: 0000000000000118
Nov 10 17:59:10 localhost kernel: [ 243.749319] RDX: ffff88012b55fe60
RSI: ffff8800280211e0 RDI: 0000000000000000
Nov 10 17:59:10 localhost kernel: [ 243.749320] RBP: ffffffff81012aee
R08: 000000000000000e R09: ffffffff81795be0
Nov 10 17:59:10 localhost kernel: [ 243.749322] R10: 8000000000000563
R11: 8000000000000573 R12: ffffffff81516179
Nov 10 17:59:10 localhost kernel: [ 243.749323] R13: ffff88012b55fdf8
R14: ffffffff81078449 R15: ffff88012b55fda8
Nov 10 17:59:10 localhost kernel: [ 243.749325] FS:
00007fb8fe3646e0(0000) GS:ffff880028161000(0000) knlGS:0000000000000000
Nov 10 17:59:10 localhost kernel: [ 243.749327] CS: 0010 DS: 0000 ES:
0000 CR0: 000000008005003b
Nov 10 17:59:10 localhost kernel: [ 243.749328] CR2: 00007fb8de930000
CR3: 000000012b4fd000 CR4: 00000000000006a0
Nov 10 17:59:10 localhost kernel: [ 243.749330] DR0: 0000000000000000
DR1: 0000000000000000 DR2: 0000000000000000
Nov 10 17:59:10 localhost kernel: [ 243.749331] DR3: 0000000000000000
DR6: 00000000ffff0ff0 DR7: 0000000000000400
Nov 10 17:59:10 localhost kernel: [ 243.749333] Call Trace:
Nov 10 17:59:10 localhost kernel: [ 243.749337] [<ffffffff8106294a>] ?
iomem_is_exclusive+0x8a/0xb0
Nov 10 17:59:10 localhost kernel: [ 243.749342] [<ffffffff81037cbc>] ?
devmem_is_allowed+0x2c/0x50
Nov 10 17:59:10 localhost kernel: [ 243.749346] [<ffffffff812e2828>] ?
read_mem+0xa8/0x180
Nov 10 17:59:10 localhost kernel: [ 243.749350] [<ffffffff81117314>] ?
vfs_read+0xc4/0x190
Nov 10 17:59:10 localhost kernel: [ 243.749352] [<ffffffff81117530>] ?
sys_read+0x50/0x90
Nov 10 17:59:10 localhost kernel: [ 243.749356] [<ffffffff81011f42>] ?
system_call_fastpath+0x16/0x1b
Same problem with soft lockup I have on this platform under heavy system
load but I can't get backtrace for it...
On Thu, 12 Nov 2009 11:09 +0000, "Alan Cox" <[email protected]> wrote:
> On Thu, 12 Nov 2009 00:12:09 -0200 Henrique de Moraes Holschuh
> <[email protected]> wrote:
> > On Wed, 11 Nov 2009, Robert Hancock wrote:
> > > I don't think that we prevent any access to device registers in
> > > /dev/mem - if you read something that has side effects and
> > > something breaks, well I guess you get to keep both pieces :-)
> > > There's a reason it's root-only..
> >
> > We should. Imaging /dev/mem is one of the oldest tricks in the book
> > of the forensics people, they do it to live systems to help track
> > down WTF happened to a compromised host. This kind of crap bites
> > them hard.
>
> Any forensics person who images /dev/mem needs to go back to school.
While I do agree with you, I can assure you they do it all the time at
least around here, and it is still listed as "best practice" in the
notebooks of many.
--
"One disk to rule them all, One disk to find them. One disk to bring
them all and in the darkness grind them. In the Land of Redmond
where the shadows lie." -- The Silicon Valley Tarot
Henrique Holschuh
Henrique de Moraes Holschuh <[email protected]> writes:
>
> We should. Imaging /dev/mem is one of the oldest tricks in the book of the
> forensics people, they do it to live systems to help track down WTF happened
> to a compromised host. This kind of crap bites them hard.
It seems more like a case of hurting themselves.
>
> IMO: if you're going to provide /dev/mem, make it as safe as possible.
That would also make it useless for people who want to access MMIO using
/dev/mem. Which is a lot of programs.
-Andi
--
[email protected] -- Speaking for myself only.
On Thu, 12 Nov 2009 17:44 +0100, "Andi Kleen" <[email protected]> wrote:
> Henrique de Moraes Holschuh <[email protected]> writes:
> > IMO: if you're going to provide /dev/mem, make it as safe as
> > possible.
>
> That would also make it useless for people who want to access MMIO
> using /dev/mem. Which is a lot of programs.
In this case, the problem seems to be access over /dev/mem to stuff the
kernel is already taking care of. Certainly "as safe as possible" does
not have to mean making /dev/mem useless for whatever good uses it has.
--
"One disk to rule them all, One disk to find them. One disk to bring
them all and in the darkness grind them. In the Land of Redmond
where the shadows lie." -- The Silicon Valley Tarot
Henrique Holschuh
> In this case, the problem seems to be access over /dev/mem to stuff the
> kernel is already taking care of. Certainly "as safe as possible" does
Which is often what is desired - eg debugging driver stuff.
> not have to mean making /dev/mem useless for whatever good uses it has.
It does. Plain and simple.
> > Any forensics person who images /dev/mem needs to go back to school.
>
> While I do agree with you, I can assure you they do it all the time at
> least around here, and it is still listed as "best practice" in the
> notebooks of many.
Oh dear me. Well the purpose of the kernel isn't to provide an idiot
filter, that is what the security policies and not giving people root is
for.
You have a people problem. Technical fixes to people problems rarely work.
On Thu, 12 Nov 2009 17:49 +0000, "Alan Cox" <[email protected]> wrote:
> > In this case, the problem seems to be access over /dev/mem to stuff the
> > kernel is already taking care of. Certainly "as safe as possible" does
>
> Which is often what is desired - eg debugging driver stuff.
>
> > not have to mean making /dev/mem useless for whatever good uses it has.
>
> It does. Plain and simple.
Is that the only valid use of /dev/mem, or even its main use?
--
"One disk to rule them all, One disk to find them. One disk to bring
them all and in the darkness grind them. In the Land of Redmond
where the shadows lie." -- The Silicon Valley Tarot
Henrique Holschuh
On Thu, 12 Nov 2009 15:57:49 -0200
"Henrique de Moraes Holschuh" <[email protected]> wrote:
> On Thu, 12 Nov 2009 17:49 +0000, "Alan Cox" <[email protected]> wrote:
> > > In this case, the problem seems to be access over /dev/mem to stuff the
> > > kernel is already taking care of. Certainly "as safe as possible" does
> >
> > Which is often what is desired - eg debugging driver stuff.
> >
> > > not have to mean making /dev/mem useless for whatever good uses it has.
> >
> > It does. Plain and simple.
>
> Is that the only valid use of /dev/mem, or even its main use?
These days it is the primary use. Things like X11 were historically
probably the biggest user of it, and things like LRMI sometimes need that
sort of stuff.
The X case also involves X and the kernel both working with the same
resource and in many cases that resource having registers that can crash
a system if mis-accessed.
Alan
On Thu, 12 Nov 2009 18:13 +0000, "Alan Cox" <[email protected]> wrote:
> On Thu, 12 Nov 2009 15:57:49 -0200 "Henrique de Moraes Holschuh"
> <[email protected]> wrote:
> > On Thu, 12 Nov 2009 17:49 +0000, "Alan Cox"
> > <[email protected]> wrote:
> > > > In this case, the problem seems to be access over /dev/mem to
> > > > stuff the kernel is already taking care of. Certainly "as safe
> > > > as possible" does
> > >
> > > Which is often what is desired - eg debugging driver stuff.
[...]
> > Is that the only valid use of /dev/mem, or even its main use?
>
> These days it is the primary use. Things like X11 were historically
> probably the biggest user of it, and things like LRMI sometimes need
> that sort of stuff.
Well, if debugging is the primary use, maybe the best long term plan
would be to get rid of the need for /dev/mem for anything other than
debugging, and after that is accomplished, move it to debugfs or make
it optional?
> The X case also involves X and the kernel both working with the same
> resource and in many cases that resource having registers that can
> crash a system if mis-accessed.
I see. That also tells me that whatever dark sides KMS has, it is much
better than the alternative :-)
--
"One disk to rule them all, One disk to find them. One disk to bring
them all and in the darkness grind them. In the Land of Redmond
where the shadows lie." -- The Silicon Valley Tarot
Henrique Holschuh
> Well, if debugging is the primary use, maybe the best long term plan
> would be to get rid of the need for /dev/mem for anything other than
> debugging, and after that is accomplished, move it to debugfs or make
> it optional?
/dev/mem is ABI and API. It's also part of Unix tradition and all sorts
of other stuff. It's just fine where it is.
> > The X case also involves X and the kernel both working with the same
> > resource and in many cases that resource having registers that can
> > crash a system if mis-accessed.
>
> I see. That also tells me that whatever dark sides KMS has, it is much
> better than the alternative :-)
Modern video doesn't really fit the simple kernel frame buffer model
anyway but it is important that the kernel now manages the resources for
all sorts of reasons including hotplug.
"Henrique de Moraes Holschuh" <[email protected]> writes:
> In this case, the problem seems to be access over /dev/mem to stuff the
> kernel is already taking care of.
Not sure if local APIC counts as "PCI space and the BIOS code and data
regions" but:
$ grep STRICT_DEVMEM -A 15 arch/x86/Kconfig.debug
config STRICT_DEVMEM
bool "Filter access to /dev/mem"
---help---
If this option is disabled, you allow userspace (root) access to all
of memory, including kernel and userspace memory. Accidental
access to this is obviously disastrous, but specific access can
be used by people debugging the kernel. Note that with PAT support
enabled, even in this case there are restrictions on /dev/mem
use due to the cache aliasing requirements.
If this option is switched on, the /dev/mem file only allows
userspace access to PCI space and the BIOS code and data regions.
This is sufficient for dosemu and X and all common users of
/dev/mem.
If in doubt, say Y.
> Certainly "as safe as possible" does
> not have to mean making /dev/mem useless for whatever good uses it has.
For debugging you need absolutely full access to whole address space(s).
One mistake (or intentional action) and the system is dead, this is by
design. It's BTW not very dangerous, compared to accessing flash
ROM/EEPROM/"fuses"/FPGA/CPLD/etc.
--
Krzysztof Halasa
On Thu, Nov 12, 2009 at 10:07:22PM +0100, Krzysztof Halasa wrote:
> "Henrique de Moraes Holschuh" <[email protected]> writes:
>
> > In this case, the problem seems to be access over /dev/mem to stuff the
> > kernel is already taking care of.
>
> Not sure if local APIC counts as "PCI space and the BIOS code and data
> regions" but:
>
> $ grep STRICT_DEVMEM -A 15 arch/x86/Kconfig.debug
> config STRICT_DEVMEM
> bool "Filter access to /dev/mem"
> ---help---
>
Yes, having this option turned on an access to LAPIC/IO_APIC
space will be forbidden.
-- Cyrill
On Thu, Nov 12, 2009 at 8:13 PM, Alan Cox <[email protected]> wrote:
>> Is that the only valid use of /dev/mem, or even its main use?
>
> These days it is the primary use. Things like X11 were historically
> probably the biggest user of it, and things like LRMI sometimes need that
> sort of stuff.
how does X11 get now direct access to the physical memory (instead of
/dev/mem) ?
On Tue, Feb 16, 2010 at 10:35:40AM +0200, Nameer Yarkon wrote:
> On Thu, Nov 12, 2009 at 8:13 PM, Alan Cox <[email protected]> wrote:
> >> Is that the only valid use of /dev/mem, or even its main use?
> >
> > These days it is the primary use. Things like X11 were historically
> > probably the biggest user of it, and things like LRMI sometimes need that
> > sort of stuff.
>
> how does X11 get now direct access to the physical memory (instead of
> /dev/mem) ?
The classic X server doesn't use main memory, typically just mapped
graphic card resources
(if you don't count BIOS tables and memory accessed by the video bios
running in emulation, but that is typically excluded by the check)
In fact it can't because it doesn't know the physical
addresses of its process memory.
Modern X does it through kernel modules (DRM, GEM etc.)
One reason it's needed to do it this way is IOMMUs.
-Andi
--
[email protected] -- Speaking for myself only.
On Tue, Feb 16, 2010 at 10:41 AM, Andi Kleen <[email protected]> wrote:
> Modern X does it through kernel modules (DRM, GEM etc.)
is it done by an mmap call (to the device) ?
> One reason it's needed to do it this way is IOMMUs.
why would it care about IOMMUs ? do graphic cards manipulate the memory too ?
thank you!
>
> -Andi
>
> --
> [email protected] -- Speaking for myself only.
>
> how does X11 get now direct access to the physical memory (instead of
> /dev/mem) ?
Via frame buffer devices.
If you think about things like hot-plug it's rather hard to do frame
buffer access any other way. The rules on memory types and aliasing also
make it nearly impossible to do properly with /dev/mem on a modern CPU.
Alan
