There is a shared library elf file, I use readelf -l to see the program headers, the output is:
Elf file type is DYN (Shared object file)
Entry point 0x0
There are 11 program headers, starting at offset 52
Program Headers:
Type Offset VirtAddr PhysAddr FileSiz MemSiz Flg Align
PHDR 0x000034 0x00000034 0x00000034 0x00100 0x00100 R 0x4
INTERP 0x000194 0x00000194 0x00000194 0x00013 0x00013 R 0x1
[Requesting program interpreter: /system/bin/linker]
LOAD 0x000000 0x00000000 0x00000000 0x3aa8c4 0x3aa8c4 R E 0x1000
LOAD 0x3ab1cc 0x003ac1cc 0x003ac1cc 0x062c0 0x25ee4 RW 0x1000
LOAD 0x3b2000 0x003d3000 0x003d3000 0x02561 0x02561 R E 0x1000
LOAD 0x3b4e8c 0x003d6e8c 0x003d6e8c 0x00298 0x00299 RW 0x1000
LOAD 0x3b5268 0x003d8268 0x003d8268 0x00128 0x00128 RW 0x1000
DYNAMIC 0x3b5268 0x003d8268 0x003d8268 0x00128 0x00128 RW 0x4
GNU_STACK 0x000000 0x00000000 0x00000000 0x00000 0x00000 RW 0
EXIDX 0x2e71e8 0x002e71e8 0x002e71e8 0x0b558 0x0b558 R 0x4
GNU_RELRO 0x3ab1cc 0x003ac1cc 0x003ac1cc 0x01e34 0x01e34 RW 0x4
Section to Segment mapping:
Segment Sections...
00
01 .interp
02 .interp .dynsym .dynstr .hash .gnu.version .gnu.version_d .rel.dyn .plt .text .ARM.extab .ARM.exidx .rodata
03 .data.rel.ro.local .fini_array .data.rel.ro .got .data .bss
04 .rel.plt
05 .init_array
06 .dynamic
07 .dynamic
08
09 .ARM.exidx
10 .data.rel.ro.local .fini_array .data.rel.ro .got
if the following struct represents an program header:
typedef struct {
uint32_t p_type;
Elf32_Off p_offset;
Elf32_Addr p_vaddr;
Elf32_Addr p_paddr;
uint32_t p_filesz;
uint32_t p_memsz;
uint32_t p_flags;
uint32_t p_align;
} Elf32_Phdr;
Then my question is: How to understand the difference between p_offset and p_vaddr which corresponds to Offset and VirtAddr in output of readelf -l? Will them always be the same? And will them be changed by the procedure of dynamic loading?
How to understand the difference between p_offset and p_vaddr which corresponds to Offset and VirtAddr in output of readelf -l?
The runtime loader will mmap a set of pages at offset .p_offset (rounded down to pagesize) at virtual address .p_vaddr (similarly rounded down; that address will actually have some large multiple-page offset added to it for ET_DYN object).
Will them always be the same?
They aren't the same even in your example:
LOAD 0x3ab1cc 0x003ac1cc
0x3ab1 != 0x3ac1. What is guaranteed is that .p_offset % pagesize == .p_vaddr % pagesize (otherwise mmap will become impossible).
Generally speaking-
p_offset - offset within the elf file
p_vaddr - address of section after loaded to memory (say, after c runtime initialization finished)
They will not always be the same, those addresses can be configured using linker script for example. Refer to this.
As for the shared library addresses after library loaded into a process address space - this depends on process addresses space, ASLR, and more, but its safe to say that the dynamic loader will set new addresses (p_vaddr, aka execution address)
Related
While working on my bootloader project, I noticed that the resulting binary file is larger than the sum of the sizes of each section in the original ELF file.
After linking the bootloader image via ld, the ELF file is structured as follows:
$ readelf -S elfboot.elf
There are 10 section headers, starting at offset 0xa708:
Section Headers:
[Nr] Name Type Addr Off Size ES Flg Lk Inf Al
[ 0] NULL 00000000 000000 000000 00 0 0 0
[ 1] .text PROGBITS 00007e00 000e00 004bc7 00 AX 0 0 16
[ 2] .rodata PROGBITS 0000c9d0 0059d0 000638 00 A 0 0 32
[ 3] .initcalls PROGBITS 0000ec20 007c20 00000c 00 WA 0 0 4
[ 4] .exitcalls PROGBITS 0000ec30 007c30 00000c 00 WA 0 0 4
[ 5] .data PROGBITS 0000ec40 007c40 0001e0 00 WA 0 0 32
[ 6] .bss NOBITS 0000ee20 007e20 00025c 00 WA 0 0 32
[ 7] .symtab SYMTAB 00000000 007e20 0016e0 10 8 166 4
[ 8] .strtab STRTAB 00000000 009500 0011bb 00 0 0 1
[ 9] .shstrtab STRTAB 00000000 00a6bb 00004a 00 0 0 1
Key to Flags:
W (write), A (alloc), X (execute), M (merge), S (strings), I (info),
L (link order), O (extra OS processing required), G (group), T (TLS),
C (compressed), x (unknown), o (OS specific), E (exclude),
p (processor specific)
I noticed that there is a rather big gap (~7KB) between the sections .rodata and .initcalls. I also checked out the content of each section:
$ objdump -s elfboot.elf
[...]
Contents of section .rodata:
[...]
cfc0 23cf0000 80000000 2fcf0000 00010000 #......./.......
cfd0 3bcf0000 00020000 47cf0000 00040000 ;.......G.......
cfe0 54cf0000 00080000 61cf0000 00100000 T.......a.......
cff0 6ecf0000 00200000 7bcf0000 00400000 n.... ..{....#..
d000 89cf0000 00800000 ........
Contents of section .initcalls:
ec20 02b50000 6db50000 feac0000 ....m.......
Contents of section .exitcalls:
[...]
My linker script tells to align every section at a 16 byte (0x10) boundary. After
objcopy -O binary elfboot.elf elfboot.bin
the resulting binary contains a huge chunk of zero filled bytes at offset 0x5200 (0xd000 - 0x7e00) all the way to offset 0x6e20 (0xec20 - 0x7e00). Now that I know where the zero filled bytes come from, how do I remove them? For reference I added the verbose output of the linker step including the linker script used:
i686-elfboot-gcc -o elfboot.elf -T elfboot.ld ./src/arch/x86/bootstrap.o ./src/arch/x86/a20.o ./src/arch/x86/bda.o ./src/arch/x86/bios.o ./src/arch/x86/copy.o ./src/arch/x86/e820.o ./src/arch/x86/entry.o ./src/arch/x86/idt.o ./src/arch/x86/realmode_jmp.o ./src/arch/x86/setup.o ./src/arch/x86/opmode.o ./src/arch/x86/pic.o ./src/arch/x86/ptrace.o ./src/arch/x86/video.o ./src/core/bdev.o ./src/core/cdev.o ./src/core/elf.o ./src/core/input.o ./src/core/interrupt.o ./src/core/loader.o ./src/core/main.o ./src/core/module.o ./src/core/pci.o ./src/core/printf.o ./src/core/string.o ./src/core/symbol.o ./src/crypto/crc32.o ./src/drivers/ide/ide.o ./src/fs/fs.o ./src/fs/file.o ./src/fs/super.o ./src/fs/ramfs/ramfs.o ./src/fs/isofs/isofs.o ./src/lib/ata/libata.o ./src/lib/tmg/libtmg.o ./src/mm/memblock.o ./src/mm/page_alloc.o ./src/mm/slub.o ./src/mm/util.o -O2 -Wl,--verbose -nostdlib -lgcc
GNU ld (GNU Binutils) 2.31.1
Supported emulations:
elf_i386
elf_iamcu
opened script file elfboot.ld
using external linker script:
==================================================
OUTPUT_FORMAT(elf32-i386)
ENTRY(_arch_start)
SECTIONS
{
/*
* The boot stack starts at 0x6000 and grows towards lower addresses.
* The stack is designed to be only one page in size, which should be
* sufficient for the bootstrap stage.
*/
. = 0x6000;
__stack_start = .;
/*
* Buffer for reading files from the boot device. Usually boot devices
* are designed to read data in chunks of 0x200 (512) or 0x800 (2048)
* bytes. The buffer is large enough to read 4 512 or 2 2048 chunks of
* data from the disk.
*/
__buffer_start = .;
. = 0x7000;
__buffer_end = .;
/*
* Actual bootstrap stage code and data.
*/
. = 0x7E00;
__bootstrap_start = .;
.text ALIGN(0x10) : {
__text_start = .;
*(.text*)
__text_end = .;
}
.rodata ALIGN(0x10) : {
__rodata_start = .;
*(.rodata*)
__rodata_end = .;
}
/*
* This section is dedicated to all built-in modules. If a module will
* be included in the elfboot binary, the module_init function pointer
* of that module is placed in this section.
*
* Make sure to initialize built-in filesystems first as we need it to
* setup the root file system node.
*/
.initcalls ALIGN(0x10) : {
__initcalls_vfs_start = .;
/* Built-in file systems */
*(.initcalls_vfs*)
__initcalls_vfs_end = .;
__initcalls_dev_start = .;
/* Built-in devices */
*(.initcalls_dev*)
__initcalls_dev_end = .;
__initcalls_start = .;
/* Built-in modules */
*(.initcalls*)
__initcalls_end = .;
}
.exitcalls ALIGN(0x10) : {
__exitcalls_start = .;
*(.exitcalls*)
__exitcalls_end = .;
}
.data ALIGN(0x10) : {
__data_start = .;
*(.data*)
__data_end = .;
}
.bss ALIGN(0x10) : {
__bss_start = .;
*(.bss*)
__bss_end = .;
}
__bootstrap_end = .;
}
==================================================
attempt to open ./src/arch/x86/bootstrap.o succeeded
./src/arch/x86/bootstrap.o
attempt to open ./src/arch/x86/a20.o succeeded
./src/arch/x86/a20.o
attempt to open ./src/arch/x86/bda.o succeeded
./src/arch/x86/bda.o
attempt to open ./src/arch/x86/bios.o succeeded
./src/arch/x86/bios.o
attempt to open ./src/arch/x86/copy.o succeeded
./src/arch/x86/copy.o
attempt to open ./src/arch/x86/e820.o succeeded
./src/arch/x86/e820.o
attempt to open ./src/arch/x86/entry.o succeeded
./src/arch/x86/entry.o
attempt to open ./src/arch/x86/idt.o succeeded
./src/arch/x86/idt.o
attempt to open ./src/arch/x86/realmode_jmp.o succeeded
./src/arch/x86/realmode_jmp.o
attempt to open ./src/arch/x86/setup.o succeeded
./src/arch/x86/setup.o
attempt to open ./src/arch/x86/opmode.o succeeded
./src/arch/x86/opmode.o
attempt to open ./src/arch/x86/pic.o succeeded
./src/arch/x86/pic.o
attempt to open ./src/arch/x86/ptrace.o succeeded
./src/arch/x86/ptrace.o
attempt to open ./src/arch/x86/video.o succeeded
./src/arch/x86/video.o
attempt to open ./src/core/bdev.o succeeded
./src/core/bdev.o
attempt to open ./src/core/cdev.o succeeded
./src/core/cdev.o
attempt to open ./src/core/elf.o succeeded
./src/core/elf.o
attempt to open ./src/core/input.o succeeded
./src/core/input.o
attempt to open ./src/core/interrupt.o succeeded
./src/core/interrupt.o
attempt to open ./src/core/loader.o succeeded
./src/core/loader.o
attempt to open ./src/core/main.o succeeded
./src/core/main.o
attempt to open ./src/core/module.o succeeded
./src/core/module.o
attempt to open ./src/core/pci.o succeeded
./src/core/pci.o
attempt to open ./src/core/printf.o succeeded
./src/core/printf.o
attempt to open ./src/core/string.o succeeded
./src/core/string.o
attempt to open ./src/core/symbol.o succeeded
./src/core/symbol.o
attempt to open ./src/crypto/crc32.o succeeded
./src/crypto/crc32.o
attempt to open ./src/drivers/ide/ide.o succeeded
./src/drivers/ide/ide.o
attempt to open ./src/fs/fs.o succeeded
./src/fs/fs.o
attempt to open ./src/fs/file.o succeeded
./src/fs/file.o
attempt to open ./src/fs/super.o succeeded
./src/fs/super.o
attempt to open ./src/fs/ramfs/ramfs.o succeeded
./src/fs/ramfs/ramfs.o
attempt to open ./src/fs/isofs/isofs.o succeeded
./src/fs/isofs/isofs.o
attempt to open ./src/lib/ata/libata.o succeeded
./src/lib/ata/libata.o
attempt to open ./src/lib/tmg/libtmg.o succeeded
./src/lib/tmg/libtmg.o
attempt to open ./src/mm/memblock.o succeeded
./src/mm/memblock.o
attempt to open ./src/mm/page_alloc.o succeeded
./src/mm/page_alloc.o
attempt to open ./src/mm/slub.o succeeded
./src/mm/slub.o
attempt to open ./src/mm/util.o succeeded
./src/mm/util.o
attempt to open /home/croemheld/Repositories/elfboot/elfboot-toolchain/lib/gcc/i686-elfboot/8.2.0/libgcc.so failed
attempt to open /home/croemheld/Repositories/elfboot/elfboot-toolchain/lib/gcc/i686-elfboot/8.2.0/libgcc.a succeeded
(/home/croemheld/Repositories/elfboot/elfboot-toolchain/lib/gcc/i686-elfboot/8.2.0/libgcc.a)_umoddi3.o
(/home/croemheld/Repositories/elfboot/elfboot-toolchain/lib/gcc/i686-elfboot/8.2.0/libgcc.a)_udivmoddi4.o
Please note that I am not able to load the sections individually into memory, since my first stage bootloader (boot sector) simply loads the entire file at a specified offset from the boot device. To reduce the size of the second stage bootloader image, I want to try to remove the gap at link time or also if possible at all, at post link time (objcopy, ...).
given a stack like the following:
cat /proc/17019/stack
[<0>] futex_wait_queue_me+0xc4/0x120
[<0>] futex_wait+0x10a/0x250
[<0>] do_futex+0x325/0x500
[<0>] SyS_futex+0x13b/0x180
[<0>] do_syscall_64+0x73/0x130
[<0>] entry_SYSCALL_64_after_hwframe+0x3d/0xa2
[<0>] 0xffffffffffffffff
take the line futex_wait_queue_me+0xc4/0x120 as an example, what does 0xc4 and 0x120 mean?
and additionally, how can I figure out the line of code corresponding to this address?
futex_wait_queue_me+0xc4/0x120 - In call stack at this function current operation is at offset 0xc4 and total size of the function is 0x120, both are in hexadecimal format. For Kernel subroutines, you can get the corresponding line by using objdump of vmlinux provided it has debug symbols to map it.
As shown below in system_call_fastpath, current offset of 0x22 is actually 34d in disassembled output.
[root#linux ~]# cat /proc/26581/stack
[<ffffffff9f28eace>] ep_poll+0x23e/0x360
[<ffffffff9f28ff9d>] SyS_epoll_wait+0xed/0x120
[<ffffffff9f774ddb>] system_call_fastpath+0x22/0x27
[<ffffffffffffffff>] 0xffffffffffffffff
(gdb) disassemble system_call_fastpath
Dump of assembler code for function system_call_fastpath:
0xffffffff81774db9 <+0>: cmp $0x14c,%rax
0xffffffff81774dbf <+6>: jae 0xffffffff81774f43 <badsys>
0xffffffff81774dc5 <+12>: sbb %rcx,%rcx
0xffffffff81774dc8 <+15>: and %rcx,%rax
0xffffffff81774dcb <+18>: mov %r10,%rcx
0xffffffff81774dce <+21>: mov -0x7e7fd6c0(,%rax,8),%rax
0xffffffff81774dd6 <+29>: callq 0xffffffff81386770 <__x86_indirect_thunk_rax>
0xffffffff81774ddb <+34>: mov %rax,0x50(%rsp)
End of assembler dump.
(gdb)
I developed a simple pintool to list all the sections of the program's main executable image (iterating over all of its sections), and also its low and high limits using IMG_HighAddress and IMG_LowAddress; according to Pin, these return the definite limits of the image.
To my surprise, the sections went way beyond the low and high limits reported by these functions. Have I done something wrong, or are these functions inaccurate?
My image load function:
VOID ImageLoad(IMG img, VOID *v)
{
if (!IMG_IsMainExecutable(img))
return;
ADDRINT mainExeImageLowAddr = IMG_LowAddress(img);
ADDRINT mainExeImageHighAddr = IMG_HighAddress(img);
cout << "Image limits " << hex << mainExeImageLowAddr << " - " << mainExeImageHighAddr << endl;
for (SEC sec = IMG_SecHead(img); SEC_Valid(sec); sec = SEC_Next(sec))
{
cout << "Section " << SEC_Name(sec) << " at addresses 0x" << hex << SEC_Address(sec) << " - 0x" << SEC_Address(sec)+SEC_Size(sec)-1 << endl;
}
}
The results for running it on /bin/ls:
Image limits 400000 - 418b23
Section .interp at addresses 0x400200 - 0x40021b
Section .note.ABI-tag at addresses 0x40021c - 0x40023b
Section .note.gnu.build-id at addresses 0x40023c - 0x40025f
Section .dynsym at addresses 0x4002c8 - 0x400eaf
Section .rela.dyn at addresses 0x401618 - 0x4017c7
Section .rela.plt at addresses 0x4017c8 - 0x402157
Section .init at addresses 0x402158 - 0x40216f
Section .plt at addresses 0x402170 - 0x4027df
Section .text at addresses 0x4027e0 - 0x412347
Section .fini at addresses 0x412348 - 0x412355
Section .rodata at addresses 0x412360 - 0x415e86
Section .eh_frame_hdr at addresses 0x415e88 - 0x41653b
Section .eh_frame at addresses 0x416540 - 0x41851b
Section .dynstr at addresses 0x41851c - 0x418b23
Section .ctors at addresses 0x619000 - 0x61900f
Section .dtors at addresses 0x619010 - 0x61901f
Section .jcr at addresses 0x619020 - 0x619027
Section .data.rel.ro at addresses 0x619040 - 0x619a87
Section .dynamic at addresses 0x619a88 - 0x619c57
Section .got at addresses 0x619c58 - 0x619cef
Section .got.plt at addresses 0x619cf0 - 0x61a037
Section .data at addresses 0x61a040 - 0x61a23f
Section .bss at addresses 0x61a240 - 0x61af5f
Section .gnu.conflict at addresses 0x61af60 - 0x61b6f7
Section .gnu_debuglink at addresses 0x0 - 0xf
Section .gnu.prelink_undo at addresses 0x0 - 0x8ff
Section .shstrtab at addresses 0x0 - 0x12d
Have I done something wrong
Not necessarily.
It looks like Pin is trying to map ELF concepts to Windows-specific concepts, and there isn't a one-to-one mapping.
Intel documentation for IMG_HighAddress says:
Tells the highest address of any code or data loaded by the image.
This is the address of the last byte loaded by the image.
But what exactly does that mean?
ELF image loading is defined by PT_LOAD segments. You can see the segments, as well as section-to-segment mapping, in output from readelf -Wl a.out.
Usually there will be two LOAD segments: one with r-x protections covering .text, .rodata, and other read-only sections, and a second with rw- protections, covering .data, .bss and other writable sections.
It looks (from your output) like IMG_HighAddress is describing only the first LOAD segment.
You should also note that not all sections are LOADable, and the non-LOADable sections are usually not covered by any segment (and do not occupy memory at runtime). Various .debug* sections are usually not LOADable.
We know user mode applications can pass IOCTL code and data buffer to kernel device drivers by calling DeviceIoControl() API.
BOOL WINAPI DeviceIoControl(
_In_ HANDLE hDevice,
_In_ DWORD dwIoControlCode, <--Control Code
_In_opt_ LPVOID lpInBuffer, <- Input buffer pointer
_In_ DWORD nInBufferSize, <- Input buffer size
_Out_opt_ LPVOID lpOutBuffer,
_In_ DWORD nOutBufferSize,
_Out_opt_ LPDWORD lpBytesReturned,
_Inout_opt_ LPOVERLAPPED lpOverlapped
);
I've a situation, where an user mode application sometime passing an IOCTL buffer to a Kernel driver and which is causing BSOD again and again. Every time i'm getting kernel memory dump for BSOD.
So my question is, is it possible to find the exact malformed input buffer and IOCTL code which causes the BSOD from the Kernel memory dump so that I can reproduce the BSOD using simple C prog.
As you can find from the stack trace, its crashing just after ntDeviceIoContrilFile call.
kd> kb
ChildEBP RetAddr Args to Child
b8048798 805246fb 00000050 ffff0000 00000001 nt!KeBugCheckEx+0x1b
b80487e4 804e1ff1 00000001 ffff0000 00000000 nt!MmAccessFault+0x6f5
b80487e4 804ed0db 00000001 ffff0000 00000000 nt!KiTrap0E+0xcc
b80488b4 804ed15a 88e23a38 b8048900 b80488f4 nt!IopCompleteRequest+0x92
b8048904 806f2c0a 00000000 00000000 b804891c nt!KiDeliverApc+0xb3
b8048904 806ed0b3 00000000 00000000 b804891c hal!HalpApcInterrupt2ndEntry+0x31
b8048990 804e59ec 88e23a38 88e239f8 00000000 hal!KfLowerIrql+0x43
b80489b0 804ed174 88e23a38 896864c8 00000000 nt!KeInsertQueueApc+0x4b
b80489e4 f7432123 8960e9d8 8980b300 00000000 nt!IopfCompleteRequest+0x1d8
WARNING: Stack unwind information not available. Following frames may be wrong.
b80489f8 804e3d77 0000001c 0000001c 806ed070 NinjaDriver+0x1123
b8048a08 8056a9ab 88e23a8c 896864c8 88e239f8 nt!IopfCallDriver+0x31
b8048a1c 8057d9f7 89817030 88e239f8 896864c8 nt!IopSynchronousServiceTail+0x60
b8048ac4 8057fbfa 00000090 00000000 00000000 nt!IopXxxControlFile+0x611
b8048af8 b6e6a06f 00000090 00000000 00000000 nt!NtDeviceIoControlFile+0x2a
b8048b8c b6e6a5c3 00000001 00000090 00000000 Ninja+0x506f
b8048c80 b6e6ab9b 00000001 88da9898 00000090 Ninja+0x55c3
b8048d34 804df06b 00000090 00000000 00000000 Ninja+0x5b9b
b8048d34 7c90ebab 00000090 00000000 00000000 nt!KiFastCallEntry+0xf8
00f8fd7c 00000000 00000000 00000000 00000000 0x7c90ebab
Thanks in Advance,
You would need the function signature for nt!NtDeviceIoControlFile. With that info unassemble backwards from nt!NtDeviceIoControlFile's return address with ub b6e6a06f. This will show you how Ninja sets up the arguments for its call to nt!NtDeviceIoControlFile. Find the args that correspond to the ioctl code and buffer and then dump their contents.
Note that registers will have been reused so you may need to dig back further in the disassembly to get the correct values from the non-volatile registers which will have been saved on the stack before the function call.
In the windbg help file (debugger.chm) there is a very useful page titled "x86 Architecture". In this case, you may want to read the sections titled "Registers" and "Calling Conventions".
this is for an assignment at school, where I need to determine the size of the processes on the system using a system call. My code is as follows:
...
struct task_struct *p;
struct vm_area_struct *v;
struct mm_struct *m;
read_lock(&tasklist_lock);
for_each_process(p) {
printk("%ld\n", p->pid);
m = p->mm;
v = m->mmap;
long start = v->vm_start;
printk("vm_start is %ld\n", start);
}
read_unlock(&tasklist_lock);
...
When I run a user level program that calls this system call, the output that I get is:
1
vm_start is 134512640
2
EIP: 0073:[<0806e352>] CPU: 0 Not tainted ESP: 007b:0f7ecf04 EFLAGS: 00010246
Not tainted
EAX: 00000000 EBX: 0fc587c0 ECX: 081fbb58 EDX: 00000000
ESI: bf88efe0 EDI: 0f482284 EBP: 0f7ecf10 DS: 007b ES: 007b
081f9bc0: [<08069ae8>] show_regs+0xb4/0xb9
081f9bec: [<080587ac>] segv+0x225/0x23d
081f9c8c: [<08058582>] segv_handler+0x4f/0x54
081f9cac: [<08067453>] sig_handler_common_skas+0xb7/0xd4
081f9cd4: [<08064748>] sig_handler+0x34/0x44
081f9cec: [<080648b5>] handle_signal+0x4c/0x7a
081f9d0c: [<08066227>] hard_handler+0xf/0x14
081f9d1c: [<00776420>] 0x776420
Kernel panic - not syncing: Kernel mode fault at addr 0x0, ip 0x806e352
EIP: 0073:[<400ea0f2>] CPU: 0 Not tainted ESP: 007b:bf88ef9c EFLAGS: 00000246
Not tainted
EAX: ffffffda EBX: 00000000 ECX: bf88efc8 EDX: 080483c8
ESI: 00000000 EDI: bf88efe0 EBP: bf88f038 DS: 007b ES: 007b
081f9b28: [<08069ae8>] show_regs+0xb4/0xb9
081f9b54: [<08058a1a>] panic_exit+0x25/0x3f
081f9b68: [<08084f54>] notifier_call_chain+0x21/0x46
081f9b88: [<08084fef>] __atomic_notifier_call_chain+0x17/0x19
081f9ba4: [<08085006>] atomic_notifier_call_chain+0x15/0x17
081f9bc0: [<0807039a>] panic+0x52/0xd8
081f9be0: [<080587ba>] segv+0x233/0x23d
081f9c8c: [<08058582>] segv_handler+0x4f/0x54
081f9cac: [<08067453>] sig_handler_common_skas+0xb7/0xd4
081f9cd4: [<08064748>] sig_handler+0x34/0x44
081f9cec: [<080648b5>] handle_signal+0x4c/0x7a
081f9d0c: [<08066227>] hard_handler+0xf/0x14
081f9d1c: [<00776420>] 0x776420
The first process (pid = 1) gave me the vm_start without any problems, but when I try to access the second process, the kernel crashes. Can anyone tell me what's wrong, and maybe how to fix it as well? Thanks a lot!
(sorry for the bad formatting....)
edit: This is done in a Fedora 2.6 core in an uml environment.
Some kernel threads might not have mm filled - check p->mm for NULL.
Changed the code to check for null pointers:
m = p->mm;
if (m != 0) {
v = m->mmap;
if (v != 0) {
long start = v->vm_start;
printk("vm_start is %ld\n", start);
}
}
All process related information can be found at /proc filesystem at the userspace level. Inside the kernel, these information are generated via fs/proc/*.c
http://lxr.linux.no/linux+v3.2.4/fs/proc/
Looking at the file task_mmu.c, which printing all the vm_start information u can observe that all handling of vm_start field always require the mmap_sem to be locked:
down_read(&mm->mmap_sem);
for (vma = mm->mmap; vma; vma = vma->vm_next) {
clear_refs_walk.private = vma;
...
walk_page_range(vma->vm_start, vma->vm_end,
&clear_refs_walk);
For kernel threads mm will be null. So whenever you read the mm do it in the following manner.
down_read(&p->mm->mmap_sem)
if(mm) {
/* read the contents of mm*/
}
up_read(&p->mm->mmap_sem)
Also you may use get_task_mm(). With get_task_mm() you need not acquire the lock. Here is how you use it :
struct mm_struct *mm;
mm = get_task_mm(p);
if (mm) {
/* read the mm contents */
}