Hello all,
First of all, I wish a Happy New Year (with less crash, but still
enhanced tools...)
Thanks for the links, they were very useful.
I dig further in the way of analyzing the User Space, but it seems
that I'm linked to a dead-end way.
Below is a snapshot of kernel / userland stack dump.
What I've done :
- Crash is triggered by a page fault inside a kernel module (write
0 in 0xFFFFFFFF, classic).
- Using gcore to create the 'core.<pid>.bash (which is the
user task running at time of crash).
- Evaluating an EBP (between { }) chaining value (hypothesis), EIP
value (between [ ]) is then just pushed beside
The purpose of this study is to find a method to analyze futur
crashes from kernel space down to user space applications.
Do you have an idea about the cause of this non-dumping of the
memory in user-space ?
Should I use other extension as 'gcore' ?
Thank in advance.
Best regards,
Patrick Agrain
-------
===============================================================================
--------------------- Go down into User Space Territory
-----------------------
Last pt_regs of kernel stack is:
| pt_regs
00000001 094a5408 00000003
..~......TJ..... | bx cx dx
c2699fc0: 00000003 094a5408 bfd1b704 00000004
.....TJ......... | si di bp ax
c2699fd0: 0000007b ffff007b c07e0000 00000033
{...{.....~.3... | ds es fs gs
c2699fe0: 00000004 b776a416 00000073 00000246
......v.s...F... | orig_eax ip cs flags
c2699ff0: bfd1b6d8
0000007b | sp ss
v cccccccc cccccccc
....{........... | padding
|
|----------------------------------------------------------------|
|
(gdb) x/32xw
0xbfd1b680
|
0xbfd1b680: 0xbfd1b6d0 0x0000000f
0x094b4568 0x080c90b9 |
0xbfd1b690: 0x094b4568 0x080cd160
0x00001936 0x00000001 |
0xbfd1b6a0: 0x094ab9c8 0x00000000
0x094b4b48 0xbfd1b7c8 |
0xbfd1b6b0: 0x080ce9e8 0x094b4b48
0x094b4b48 0xbfd1b728 |
0xbfd1b6c0: 0x094aed28 0x00000020
0x00000000 0x00000070 |
0xbfd1b6d0: 0x094b4588
0x080cc080 |
0xb7698b43 <--|
0xb7757ff4
0xbfd1b6e0: 0xb76343b4 0x00000001
0x094a5408 0x00000003
0xbfd1b6f0: 0xb77584e0 0x080cc080
0xbfd1b728 0xb77584e0
|------------------------------------------ Hypothesis : this is
an EBP value...
v
0xbfd1b700: 0x00000003 {0xbfd1b72c}
[0xb7635c90] 0xb77584e0
0xbfd1b710: 0x094a5408 0x00000003
0x094b4b48 0xbfd1b7c8
0xbfd1b720: 0xb7757ff4 0xb77584e0
0x0000000a {0xbfd1b750}
0xbfd1b730: [0xb7634e80] 0xb77584e0
0x094a5408 0x00000003
0xbfd1b740: 0x0000000a 0xb7757ff4
0xb77584e0 0x0000000a
0xbfd1b750: {0xbfd1b768} [0xb7637d2a]
0xb77584e0 0x0000000a
0xbfd1b760: 0xb7757ff4 0xb77584e0
{0xbfd1b788} [0xb76312b5] >-|
0xbfd1b770: 0xb77584e0 0x0000000a
0xb75c9940 0x094a3e48 |
0xbfd1b780: 0x00000001 0x00000000
0x00000000 0x0809b64b |
|
Disassemble Try: EIP@0xb76312b5
<---------------------------------------------|
(gdb) disassemble 0xb7631200, 0xb7631300
Dump of assembler code from 0xb7631200 to 0xb7631300:
0xb7631200: Cannot access memory at address
0xb7631200
(gdb)
----------
Le 17/12/2013 19:12, Buland Kumar Singh a écrit :