pmap

[rup]

Hallo,

kann mir jemand die Ausgabe von pmap erklaeren ("man pmap" sagt nicht viel)

* Weshalb sehe ich z.B. /lib/libc-2.7.so 4x (-----, r----, rw---, r-x--) es gibt aber noch etliche andere Permissions z.B auf einem anderen System 4 stellig: (---p, r-xp, rwxp ...)
* Was ist [ anon ] (anonymous memory). Wird dieser pro "sleep" Instance verwendet, oder von allen geteilt?
* Was ist [ vdso ] (in diesem Beispiel nicht mit dabei)
* [stack] scheint der Stack zu sein, wo sehe ich den Heap?
* Die Daten scheinen von /proc/<pid>/smaps zu kommen.

Wo kann ich mich am besten ueber das ganze schlau-machen?




$ pmap 12590
12590: sleep 1000
0000000000400000 28K r-x-- /bin/sleep
0000000000607000 4K rw--- /bin/sleep
0000000000608000 132K rw--- [ anon ]
00007f39f15a6000 88K r-x-- /lib/libpthread-2.7.so
00007f39f15bc000 2048K ----- /lib/libpthread-2.7.so
00007f39f17bc000 8K rw--- /lib/libpthread-2.7.so
00007f39f17be000 16K rw--- [ anon ]
00007f39f17c2000 1376K r-x-- /lib/libc-2.7.so
00007f39f191a000 2048K ----- /lib/libc-2.7.so
00007f39f1b1a000 12K r---- /lib/libc-2.7.so
00007f39f1b1d000 8K rw--- /lib/libc-2.7.so
00007f39f1b1f000 20K rw--- [ anon ]
00007f39f1b24000 32K r-x-- /lib/librt-2.7.so
00007f39f1b2c000 2044K ----- /lib/librt-2.7.so
00007f39f1d2b000 8K rw--- /lib/librt-2.7.so
00007f39f1d2d000 116K r-x-- /lib/ld-2.7.so
00007f39f1ef5000 252K r---- /usr/lib/locale/en_US.utf8/LC_CTYPE
00007f39f1f34000 4K r---- /usr/lib/locale/en_US.utf8/LC_NUMERIC
00007f39f1f35000 4K r---- /usr/lib/locale/en_US.utf8/LC_TIME
00007f39f1f36000 4K r---- /usr/lib/locale/en_US.utf8/LC_MONETARY
00007f39f1f37000 28K r--s- /usr/lib/gconv/gconv-modules.cache
00007f39f1f3e000 8K rw--- [ anon ]
00007f39f1f40000 4K r---- /usr/lib/locale/en_US.utf8/LC_MESSAGES/SYS_LC_MESSAGES
00007f39f1f41000 4K r---- /usr/lib/locale/en_US.utf8/LC_PAPER
00007f39f1f42000 4K r---- /usr/lib/locale/en_US.utf8/LC_NAME
00007f39f1f43000 4K r---- /usr/lib/locale/en_US.utf8/LC_ADDRESS
00007f39f1f44000 4K r---- /usr/lib/locale/en_US.utf8/LC_TELEPHONE
00007f39f1f45000 4K r---- /usr/lib/locale/en_US.utf8/LC_MEASUREMENT
00007f39f1f46000 4K r---- /usr/lib/locale/en_US.utf8/LC_IDENTIFICATION
00007f39f1f47000 12K rw--- [ anon ]
00007f39f1f4a000 8K rw--- /lib/ld-2.7.so
00007ffff9f37000 84K rw--- [ stack ]
00007ffff9ffe000 8K r-x-- [ anon ]
ffffffffff600000 4K r-x-- [ anon ]
total 8432K

[Immortal]

Q: VDSO?
A: Virtual Dynamically-Linked Object (aka "virtual libraries"). Wird vom Kernel bereitgestellt und hilft Userspace-Programmen bestimmte Kernel-Funktionen ohne den Overhead von Syscalls durchzufuehren. Dabei wird automatisch die "bessere" CPU-Instruktion gewaehlt: Also das alte "int 80h", um Syscalls aufzurufen, oder die sogenannten Fast-Control-Transfer-Instruktionen SYSCALL/SYSENTER (Intel/AMD). Letztere sind besser da weniger Kontext-Wechsel.

Q: Anonymous memory?
A: Anonymer Speicher wird fuer viele Sachen, u.a. Heap oder Thread-Stacks verwendet. Kannst ja mal den Adress-Bereich von "grep heap /proc/<pid>/{s,}maps" mit dem von "pmap <pid>" vergleichen: Heap-Bereiche werden als [anon] angezeigt.

Alles in allem ist procps' Implementierung von 'pmap' ziemlich doof. Von der nicht vorhandenen Doku mal ganz zu schweigen. Zum Vergleich: http://compute.cnr.berkeley.edu/cgi-bin/man-cgi?pmap+1.

HTH

[403]

Beispiel für heap, allerdings mit cat /proc/pid/maps:



$ ./overflow
*** stack smashing detected ***: ./overflow terminated
======= Backtrace: =========
/lib/tls/i686/cmov/libc.so.6(__fortify_fail+0x48)[0xb7f67da8]
/lib/tls/i686/cmov/libc.so.6(__fortify_fail+0x0)[0xb7f67d60]
./overflow[0x804845c]
[0x41414141]
======= Memory map: ========
08048000-08049000 r-xp 00000000 08:06 3704767 /home/ordonez/Documents/Development/C/overflow
08049000-0804a000 r--p 00000000 08:06 3704767 /home/ordonez/Documents/Development/C/overflow
0804a000-0804b000 rw-p 00001000 08:06 3704767 /home/ordonez/Documents/Development/C/overflow
0804b000-0806c000 rw-p 0804b000 00:00 0 [heap]
b7e5a000-b7e67000 r-xp 00000000 08:06 368705 /lib/libgcc_s.so.1
b7e67000-b7e68000 r--p 0000c000 08:06 368705 /lib/libgcc_s.so.1
b7e68000-b7e69000 rw-p 0000d000 08:06 368705 /lib/libgcc_s.so.1
b7e69000-b7e6a000 rw-p b7e69000 00:00 0
b7e6a000-b7fc6000 r-xp 00000000 08:06 386037 /lib/tls/i686/cmov/libc-2.9.so
b7fc6000-b7fc7000 ---p 0015c000 08:06 386037 /lib/tls/i686/cmov/libc-2.9.so
b7fc7000-b7fc9000 r--p 0015c000 08:06 386037 /lib/tls/i686/cmov/libc-2.9.so
b7fc9000-b7fca000 rw-p 0015e000 08:06 386037 /lib/tls/i686/cmov/libc-2.9.so
b7fca000-b7fcd000 rw-p b7fca000 00:00 0
b7fdf000-b7fe1000 rw-p b7fdf000 00:00 0
b7fe1000-b7fe2000 r-xp b7fe1000 00:00 0 [vdso]
b7fe2000-b7ffe000 r-xp 00000000 08:06 368654 /lib/ld-2.9.so
b7ffe000-b7fff000 r--p 0001b000 08:06 368654 /lib/ld-2.9.so
b7fff000-b8000000 rw-p 0001c000 08:06 368654 /lib/ld-2.9.so
bffeb000-c0000000 rw-p bffeb000 00:00 0 [stack]
Aborted


Quelle http://ubuntuforums.org/showthread.php?t=1338901


Interessant wird es, wenn eine Seite ausführbar und beschreibbar ist.
Im Zusammenhang mit dem Testen von ASLR vielleicht noch erwähnenswert:

/proc/sys/kernel/randomize_va_space


Gruss
403

PS,


No standards apply, but pmap looks an awful lot like a SunOS command.

[Immortal]

Wie bist du von "Heap-Bereiche anzeigen" zu "Buffer Overflows und ASLR" gekommen? :]

Diesen Backtrace bekommt man uebrigens nur, wenn man mit gcc's "-fstack-protector"-Feature kompiliert hat. (ASLR ist dabei unerheblich.)

[403]

abend,

Oops :]

Hm, ich musste kürzlich fnostack-protector verwenden ;)
@backtrace, ja kann ja sein, es ging mir hauptsächlich um die maps.

Gruss
403

[rup]

ich bin immer noch am gruebeln und kapiers einfach nicht :-(

Ich hab mal ein kleines Prog geschrieben mit einer lib die in einer Schleife malloc aufruft, hier die Ausgabe von 2 verschiedenen Prozessen
Die Library ist eine shared lib (gcc -shared -o lib/libstuff.so memLeak.o)
Man sieht schoen wie der heap waechst. Was ich nicht verstehe ist weshalb "0K shared".

Was wird nun pro a.out Instanz Speicher allokiert, was wird geteilt,
Wie kann ich nun berechnen was die beiden a.out Prozesse zusammen an Speicher benoetigen, was wuerde eine 3. a.out Prozess an zusaetzlichen Speicher benoetigen.




$ pmap 7084
7084: a.out
START SIZE RSS DIRTY PERM MAPPING
08048000 4K 4K 0K r-xp /home/rup/tmp/a.out
08049000 4K 4K 4K r--p /home/rup/tmp/a.out
0804a000 4K 4K 4K rw-p /home/rup/tmp/a.out
0804b000 792K 768K 768K rw-p [heap]
b7dc6000 4K 4K 4K rw-p [anon]
b7dc7000 1204K 204K 0K r-xp /lib/libc-2.6.1.so
b7ef4000 4K 4K 4K r--p /lib/libc-2.6.1.so
b7ef5000 8K 8K 8K rw-p /lib/libc-2.6.1.so
b7ef7000 12K 12K 12K rw-p [anon]
b7f10000 4K 4K 4K rw-p [anon]
b7f11000 4K 4K 4K r-xp /home/rup/tmp/lib/libstuff.so
b7f12000 4K 4K 4K r--p /home/rup/tmp/lib/libstuff.so
b7f13000 4K 4K 4K rw-p /home/rup/tmp/lib/libstuff.so
b7f14000 4K 4K 4K rw-p [anon]
b7f15000 104K 92K 0K r-xp /lib/ld-2.6.1.so
b7f2f000 8K 8K 8K rw-p /lib/ld-2.6.1.so
bfb1b000 88K 12K 12K rw-p [stack]
ffffe000 4K 0K 0K r-xp [vdso]
Total: 2260K 1144K 844K

928K writable-private, 1332K readonly-private, 0K shared, and 1144K referenced





$ pmap 7106
7106: a.out
START SIZE RSS DIRTY PERM MAPPING
08048000 4K 4K 0K r-xp /home/rup/tmp/a.out
08049000 4K 4K 4K r--p /home/rup/tmp/a.out
0804a000 4K 4K 4K rw-p /home/rup/tmp/a.out
0804b000 660K 572K 572K rw-p [heap]
b7e6f000 4K 4K 4K rw-p [anon]
b7e70000 1204K 204K 0K r-xp /lib/libc-2.6.1.so
b7f9d000 4K 4K 4K r--p /lib/libc-2.6.1.so
b7f9e000 8K 8K 8K rw-p /lib/libc-2.6.1.so
b7fa0000 12K 12K 12K rw-p [anon]
b7fb9000 4K 4K 4K rw-p [anon]
b7fba000 4K 4K 4K r-xp /home/rup/tmp/lib/libstuff.so
b7fbb000 4K 4K 4K r--p /home/rup/tmp/lib/libstuff.so
b7fbc000 4K 4K 4K rw-p /home/rup/tmp/lib/libstuff.so
b7fbd000 4K 4K 4K rw-p [anon]
b7fbe000 104K 92K 0K r-xp /lib/ld-2.6.1.so
b7fd8000 8K 8K 8K rw-p /lib/ld-2.6.1.so
bfbf8000 84K 8K 8K rw-p [stack]
ffffe000 4K 0K 0K r-xp [vdso]
Total: 2124K 944K 644K

792K writable-private, 1332K readonly-private, 0K shared, and 944K referenced

[Immortal]

Hmm, das ist bei Linux ja komplizierter als man denkt. Ich glaube das es ungefaehr so ist..



for i in $(pgrep -U $USER); do echo -n "$(< /proc/$i/comm) $i "; pmap -d $i | tail -1; done | column -t


Wobei "mapped" die Groesse beschreibt, die der Prozess einnehmen wuerde, wenn er der einzige auf dem System waere. Das passiert natuerlich nie. Das ist die gleiche Groesse, die man mit "ps -o vsz <pid>" bekommt. "writable/shared" ist die "incremental memory usage" die wirklich dazu kommt, wenn man einen Prozess startet.

(Ohne Gewaehr :))