I wrote a simple kernel module file, after I insmod it, I want to find it's address symbol,so I execute:
root#hmd8890:/ # cat /proc/modules
hellotest 878 0 - Live 0x0000000000000000 (O)
or:
root#hmd8890:/ # cat /sys/module/hellotest/sections/.init.text
0x0000000000000000
but the address symbol are all 0x0000000000000000, I think it should be as:
[root#vexpress mnt]# cat /proc/modules
hellotest 797 0 - Live 0xbf000000 (O)
0xbf000000 is ok for me.
How can I find the right symbol table? Do I miss the kernelconfig file select options? Thanks for your suggestions.
Related
I have a memory crash dump, and I can list processes with !process 0 0
What I want to do is find the Image Base Address of calc.exe and get its contents from the memory. Potentially saving it into a file.
what do I need to do to achieve that?
Edit: the type of dump I have is "automatic dump" but I would like to know the technique for other types such as full core dump
a dump can be of several types
what is the type of dump is it user mode or kernel mode ?
it is mindump of full dump ?
in many cases the pages may not be present either being paged out or intentionally discarded init section of modules
anyway
if user mode try !vadump or !address to locate the module of interest find its start address and end address and try dumping in page size increments (0x1000 bytes )using .writemem
in kmode use !vad
and follow both commands by lm or !dh to get the module information in both user mode and kernelmode
here is an user mode dump !address info
F:\caldump>cdb -c "!address calculator;q" -z calc.dmp | awk "/Reading/,/quit/"
0:023> cdb: Reading initial command '!address calculator;q'
Usage: Image
Base Address: 00007ff7`04a30000
End Address: 00007ff7`04a31000
Region Size: 00000000`00001000 ( 4.000 kB)
State: 00001000 MEM_COMMIT
Protect: 00000002 PAGE_READONLY
Type: 01000000 MEM_IMAGE
Allocation Base: 00007ff7`04a30000
Allocation Protect: 00000080 PAGE_EXECUTE_WRITECOPY
Image Path: C:\Program Files\WindowsApps\Microsoft.WindowsCalculator_10.1906.55.0_x64__8wekyb3d8bbwe\Calculator.exe
Module Name: Calculator
Loaded Image Name:
Mapped Image Name:
More info: lmv m Calculator
More info: !lmi Calculator
More info: ln 0x7ff704a30000
More info: !dh 0x7ff704a30000
Since !process 0 0 works then it's a kernel dump. Try inspecting the peb
https://learn.microsoft.com/en-us/windows-hardware/drivers/debugger/-peb
I have a full dump of a VM with windows 10 installed. This dump was taken from a hard hanged system, frozen mouse and keyboard, totally unresponsive.
While analyzing I found that there are no thread in running or ready state. No deadlocks. Only suspicious thing is that there are a lot of thread waiting for a reply from ALPC and also there is page fault pattern in as lot of threads that looks like this:
ffffbc0f`151380f0 fffff805`1e4e081c Ntfs!NtfsNonCachedIo+0x4ea
ffffbc0f`151383b0 fffff805`1e4df8bc Ntfs!NtfsCommonRead+0xd2c
ffffbc0f`151385b0 fffff805`19687d3a Ntfs!NtfsFsdRead+0x1fc
ffffbc0f`15138680 fffff805`19687ce7 nt!IopfCallDriver+0x46
ffffbc0f`151386c0 fffff805`1d926ccf nt!IofCallDriver+0x17
ffffbc0f`151386f0 fffff805`1d9248d3 FLTMGR!FltpLegacyProcessingAfterPreCallbacksCompleted+0x28f
ffffbc0f`15138760 fffff805`19687d3a FLTMGR!FltpDispatch+0xa3
ffffbc0f`151387c0 fffff805`19687ce7 nt!IopfCallDriver+0x46
ffffbc0f`15138800 fffff805`196215b2 nt!IofCallDriver+0x17
ffffbc0f`15138830 fffff805`196221e2 nt!IoPageReadEx+0x1e6
ffffbc0f`151388a0 fffff805`19622eee nt!MiIssueHardFaultIo+0xb6
ffffbc0f`151388f0 fffff805`19666566 nt!MiIssueHardFault+0x48e
ffffbc0f`151389f0 fffff805`197aba1e nt!MmAccessFault+0x276
ffffbc0f`15138b00 00007ffd`2e42ec10 nt!KiPageFault+0x35e (TrapFrame # ffffbc0f`15138b00)
also almost every thread (maybe I've seen 1 or 2 that don't) in every process ends with this:
ffffbc0f`15d08df0 fffff805`1966aad4 nt!KiSwapContext+0x76
ffffbc0f`15d08f30 fffff805`196657ca nt!KiSwapThread+0x190
ffffbc0f`15d08fa0 fffff805`19666fb0 nt!KiCommitThreadWait+0x13a
ffffbc0f`15d09050 fffff805`1e4e261a nt!KeWaitForSingleObject+0x140
I have one particular example of a thread with a page fault belonging to a prl_tools_service.exe (which is Parallels VM related service) that has same pattern and when looking into trap frame at the moment of KiPageFault there was an attempt to get value from an address in eax and in trap frame rax=0000000000000001 which can't be a valid address and I can't see how this page fault can be resolved.
IRQLs of both processors are LOW_LEVEL
The question, basically, is - where should I look for any faults since there must be a kernel problem (hence mouse and keyboard freeze) and how do I find wether this example of page fault pattern could stall the kernel.
Since the question is pretty vague any kind of response, a direction where to look, a hint - every thing will be much appreciated
UPD: as requested by Lieven Keersmaekers and blabb here is !analyze -hang output:
0: kd> !analyze -hang
*******************************************************************************
* *
* Bugcheck Analysis *
* *
*******************************************************************************
Unknown bugcheck code (0)
Unknown bugcheck description
Arguments:
Arg1: 0000000000000000
Arg2: 0000000000000000
Arg3: 0000000000000000
Arg4: 0000000000000000
Debugging Details:
------------------
Scanning for threads blocked on locks ...
Cannot get _ERESOURCE type
BUGCHECK_CODE: 0
BUGCHECK_P1: 0
BUGCHECK_P2: 0
BUGCHECK_P3: 0
BUGCHECK_P4: 0
PROCESS_NAME: System
ERROR_CODE: (NTSTATUS) 0x45474150 - <Unable to get error code text>
SYMBOL_NAME: nt!PpmIdleGuestExecute+1d
MODULE_NAME: nt
IMAGE_NAME: ntkrnlmp.exe
FAILURE_BUCKET_ID: 0x0_STACKPTR_ERROR_nt!PpmIdleGuestExecute
FAILURE_ID_HASH: {94784d45-ed21-c95f-fc42-87fec626bbee}
Followup: MachineOwner
---------
I'm trying to figure out how does reading from mmapped file can trigger KERN_MEMORY_ERROR if the address reside within the memory borders.
Here's an example for one such crash, where trying to read from lmdb formatted file (possibly corrupted). It can clearly be seen that the invalid address reside inside the mapped file region which is the lmdb mapped file.
Thus, any attempt to access address within the mapped range can either retrieve the page contents directly from memory, or trigger page fault trap that eventually lead to reading the missing data from disk and return it to process as well.
One thing that raise some concerns is that the file size is only 24k and the mapping spans over 256M. However, the file's meta data seems to be coherent to file contents.
Exception Type: EXC_BAD_ACCESS (SIGBUS)
Exception Codes: KERN_MEMORY_ERROR at 0x000000010648800a
Exception Note: EXC_CORPSE_NOTIFY
Termination Signal: Bus error: 10
Termination Reason: Namespace SIGNAL, Code 0xa
Terminating Process: exc handler [0]
VM Regions Near 0x10648800a:
__LINKEDIT 0000000106464000-000000010647f000 [ 108K] r--/rwx SM=COW ^Z^C [/usr/lib/dyld]
--> mapped file 000000010647f000-000000011647f000 [256.0M] r--/rwx SM=PRV Object_id=9034edd9
STACK GUARD 000070000f2b3000-000070000f2b4000 [ 4K] ---/rwx SM=NUL stack guard for thread 1
Thread 0 Crashed:: Dispatch queue: com.apple.main-thread
0 myprog 0x0000000101666756 mdb_page_search_root + 39
1 myprog 0x00000001016660f7 mdb_page_search + 182
2 myprog 0x00000001016614de mdb_cursor_set + 88
3 myprog 0x0000000101661476 mdb_get + 134
What is the meaning of (OE+) in the following?
$ sudo cat /proc/modules | grep hello //hello_world is a kernel module created by me.
hello_world 20480 1 - Loading 0xffffffffc0221000 (OE+)
Here is my situation.
I have patched the Linux kernel function load_module(), which is called from finit_module(), the system call used by insmod to insert kernel modules.
The patch looks for a specific module, created by me (called hello_world) being installed, and when it does, it prevents the call to do_init_module(), and returns 0 instead. do_init_call() is responsible for calling a module's init function, and setting the module state to live (MODULE_STATE_LIVE).
When I read /proc/modules, the module state is Loading, which is expected. I do not understand however the meaning of (OE+) at the end of output. This is not displayed against any other module, as is verified by the following command.
$ sudo cat /proc/modules | grep OE
hello_world 20480 1 - Loading 0xffffffffc0221000 (OE+)
I am using Linux kernel v4.7.3.
Update
All this is happening in a Qemu virtual machine. On the host, which is running Linux 4.4.0-36-generic (Ubuntu), I get the following.
$ sudo cat /proc/modules | grep OE
vboxpci 24576 0 - Live 0xffffffffc082a000 (OE)
vboxnetadp 28672 0 - Live 0xffffffffc066e000 (OE)
vboxnetflt 28672 0 - Live 0xffffffffc0635000 (OE)
vboxdrv 454656 3 vboxpci,vboxnetadp,vboxnetflt, Live 0xffffffffc0783000 (OE)
sep4_0 671744 0 - Live 0xffffffffc06de000 (OE)
socperf2_0 36864 1 sep4_0, Live 0xffffffffc0660000 (OE)
pax 16384 0 - Live 0xffffffffc05f9000 (OE)
O means Out-of-tree module has been loaded.
E means Unsigned module has been loaded.
+ means that the module is being loaded.
- means that the module is being unloaded.
The source code for print_modules(), then module_flags(), and then print_tainted() functions may be helpful in figuring out the meaning of these and some other flags. Take a look at the comment just above print_tainted() function. Hope this helps.
Is there a way to get the instruction pointer of a running application Unix?
I have a running process (C++) and want to get its current location, and thereafter in GDB (on a different machine) map the location to source location ('list' command).
On Linux, there is /proc/[pid]/stat.
From "man proc":
stat Status information about the process. This is used by
ps(1). It is defined in /usr/src/linux/fs/proc/array.c.
...
kstkeip %lu
The current EIP (instruction pointer).
AFAICT, the 29th field of the output corresponds to the current instruction pointer of the process. For example:
gdb date
GNU gdb Red Hat Linux (6.0post-0.20040223.20rh)
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "x86_64-redhat-linux-gnu"...(no debugging symbols found)...Using host libthread_db library "/lib64/tls/libthread_db.so.1".
(gdb) set stop-on-solib-events 1
(gdb) run
(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...[Thread debugging using libthread_db enabled]
[New Thread 182896391360 (LWP 27968)]
(no debugging symbols found)...Stopped due to shared library event
(gdb) c
[Switching to Thread 182896391360 (LWP 27968)]
Stopped due to shared library event
(gdb) where
#0 0x00000036b060bb20 in _dl_debug_state_internal () from /lib64/ld-linux-x86-64.so.2
#1 0x00000036b060b51c in _dl_init_internal () from /lib64/ld-linux-x86-64.so.2
#2 0x00000036b0600f72 in _dl_start_user () from /lib64/ld-linux-x86-64.so.2
#3 0x0000000000000001 in ?? ()
#4 0x0000007fbff62728 in ?? ()
#5 0x0000000000000000 in ?? ()
(gdb) shell cat /proc/27968/stat
27968 (date) T 27839 27968 8955 34817 27839 4194304 42 0 330 0 0 0 0 0 18 0 0 0 1881668573 6144000 78 18446744073709551615 4194304 4234416 548680739552 18446744073709551615 234887363360 0 0 0 0 18446744071563322838 0 0 17 0 0 0 0 0 0 0
(gdb) p/a 234887363360 <--- the value of 29th field
$1 = 0x36b060bb20 <_dl_debug_state_internal>
The instruction pointer can be retrieved on Linux with the following code:
pid_t traced_process;
struct user_regs_struct regs;
ptrace(PTRACE_ATTACH, traced_process, NULL, NULL);
ptrace(PTRACE_GETREGS, traced_process, NULL, ®s);
printf("EIP: %lx\n", regs.eip);
You will need to temporarily stop the process or thread in order to get its current instruction pointer. You can do it by attaching to the process with ptrace() or (on HP-UX) ttrace() and accessing the registers.
If you're using gdb anyway, you can simply attach yourself to a running process like this:
gdb program 1234
where program is the name of the executable you're debugging, and 1234 is the PID. You can then use all of the facilities of gdb to debug the process.