Reading /dev/mem by dd

Reading /dev/mem by dd

[Anton D. Kachalov]

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

Re: Reading /dev/mem by dd

[Américo Wang]

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 majordomo@vger.kernel.org
> 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.
 

Re: Reading /dev/mem by dd

[Robert Hancock]

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..

Re: Reading /dev/mem by dd

[Henrique de Moraes Holschuh]

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

Re: Reading /dev/mem by dd

[Alan Cox]

On Thu, 12 Nov 2009 00:12:09 -0200
Henrique de Moraes Holschuh <hmh@hmh.eng.br> 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

Re: Reading /dev/mem by dd

[Anton D. Kachalov]

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...

Re: Reading /dev/mem by dd

[Henrique de Moraes Holschuh]

On Thu, 12 Nov 2009 11:09 +0000, "Alan Cox" <alan@lxorguk.ukuu.org.uk> wrote:
> On Thu, 12 Nov 2009 00:12:09 -0200 Henrique de Moraes Holschuh
> <hmh@hmh.eng.br> 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

Re: Reading /dev/mem by dd

[Andi Kleen]

Henrique de Moraes Holschuh <hmh@hmh.eng.br> 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

-- 
ak@linux.intel.com -- Speaking for myself only.

Re: Reading /dev/mem by dd

[Henrique de Moraes Holschuh]

On Thu, 12 Nov 2009 17:44 +0100, "Andi Kleen" <andi@firstfloor.org> wrote:
> Henrique de Moraes Holschuh <hmh@hmh.eng.br> 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

Re: Reading /dev/mem by dd

[Alan Cox]

> 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.

Re: Reading /dev/mem by dd

[Alan Cox]

> > 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.

Re: Reading /dev/mem by dd

[Henrique de Moraes Holschuh]

On Thu, 12 Nov 2009 17:49 +0000, "Alan Cox" <alan@lxorguk.ukuu.org.uk> 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

Re: Reading /dev/mem by dd

[Alan Cox]

On Thu, 12 Nov 2009 15:57:49 -0200
"Henrique de Moraes Holschuh" <hmh@hmh.eng.br> wrote:

> On Thu, 12 Nov 2009 17:49 +0000, "Alan Cox" <alan@lxorguk.ukuu.org.uk> 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

Re: Reading /dev/mem by dd

[Henrique de Moraes Holschuh]

On Thu, 12 Nov 2009 18:13 +0000, "Alan Cox" <alan@lxorguk.ukuu.org.uk> wrote:
> On Thu, 12 Nov 2009 15:57:49 -0200 "Henrique de Moraes Holschuh"
> <hmh@hmh.eng.br> wrote:
> > On Thu, 12 Nov 2009 17:49 +0000, "Alan Cox"
> > <alan@lxorguk.ukuu.org.uk> 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

Re: Reading /dev/mem by dd

[Alan Cox]

> 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.

Re: Reading /dev/mem by dd

[Krzysztof Halasa]

"Henrique de Moraes Holschuh" <hmh@hmh.eng.br> 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

Re: Reading /dev/mem by dd

[Cyrill Gorcunov]

On Thu, Nov 12, 2009 at 10:07:22PM +0100, Krzysztof Halasa wrote:
> "Henrique de Moraes Holschuh" <hmh@hmh.eng.br> 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

Re: Reading /dev/mem by dd

[Alan Cox]

> 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

Re: Reading /dev/mem by dd

[Nameer Yarkon]

On Tue, Feb 16, 2010 at 10:41 AM, Andi Kleen <andi@firstfloor.org> 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
>
> --
> ak@linux.intel.com -- Speaking for myself only.
>

Re: Reading /dev/mem by dd

[Andi Kleen]

On Tue, Feb 16, 2010 at 10:35:40AM +0200, Nameer Yarkon wrote:
> On Thu, Nov 12, 2009 at 8:13 PM, Alan Cox <alan@lxorguk.ukuu.org.uk> 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

-- 
ak@linux.intel.com -- Speaking for myself only.

Re: Reading /dev/mem by dd

[Nameer Yarkon]

On Thu, Nov 12, 2009 at 8:13 PM, Alan Cox <alan@lxorguk.ukuu.org.uk> 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) ?