程涵
原创博客
《Linux内核分析》MOOC课程http://mooc.study.163.com/course/USTC-1000029000
可执行程序的装载
知识点梳理
一、预处理、编译、链接和目标文件的格式
可执行程序是如何得来的
- C源代码(.c)经过编译器预处理被编译成汇编代码(.asm)
- 汇编代码由汇编器被编译成目标代码(.o)
- 将目标代码链接成可执行文件(a.out)
- 可执行文件由操作系统加载到内存中执行
vi hello.c gcc -E -o hello.cpp hello.c -m32 //预处理.c文件，预处理包括把include的文件包含进来以及宏替换等工作 vi hello.cpp gcc -x cpp-output -S -o hello.s hello.cpp -m32 //编译成汇编代码.s vi hello.s gcc -x assembler -c hello.s -o hello.o -m32 //将汇编代码.s编译成二进制目标文件.o（不可读，含有部分机器指令但不可执行） vi hello.o gcc -o hello hello.o -m32 //将目标文件链接成可执行二进制文件hello vi hello gcc -o hello.static hello.o -m32 -static
目标文件的格式ELF
1. .out是最古老的可执行文件，目前Windows系统上多是PE，Linux系统上多是ELF。ELF文件已经是适应到某一种CPU体系结构的二进制兼容文件了
2. 目标文件的三种形式：
- 可重定位文件.o,用来和其他object文件一起创建可执行文件和共享文件
- 可执行文件，指出应该从哪里开始执行
- 共享文件，主要是.so文件，用来被链接编辑器和动态链接器链接
3. ELF格式
- ELF头描述了该文件的组织情况，程序投标告诉系统如何创建一个进程的内存映像，section头表包含了描述文件sections的信息。当系统要执行一个文件的时候，理论上它会把程序段拷贝到虚拟内存中某个段
- ELF文件的头部规定了许多与二进制兼容性相关的信息。所以在加载ELF文件的时候，必须先加载头部，分析ELF的具体信息
- entry代表刚加载过新的可执行文件之后的程序的入口地址，头部后是代码和数据，进程的地址空间是4G，上面的1G是内核用，下面的3G是程序使用。默认的ELF头加载地址是0x8048000
静态链接的ELF可执行文件和进程的地址空间
1. Entry point address：入口地址为0x8048X00（不唯一）
加载效果：将代码段数据加载到内存中，再把数据加载到内存，默认从0x8048000地址开始加载
启动一个刚加载过可执行文件的进程时，可执行文件加载到内存之后执行的第一条代码地址
一般静态链接会将所有代码放在一个代码段，而动态链接的进程会有多个代码段
2. 流程
- 分析头部
- 查看是否需要动态链接。如果是静态链接的ELF文件，那么直接加载文件即可。如果是动态链接的可执行文件，那么需要加载的是动态链接器
- 装载文件，为其准备进程映像
- 为新的代码段设定寄存器以及堆栈信息
二、可执行程序、共享库和动态链接
可执行程序的执行环境
- 一般执行一个程序的Shell环境，实验中直接使用execve系统调用
- Shell本身不限制命令行参数的个数，命令行参数的个数受限于命令自身，如：
int main(int argc, char *argv[]) int main(int argc, char argv[], char envp[])//envp是shell的执行环境
- Shell会调用execve将命令行参数和环境参数传递给可执行程序的main函数
int execve(const char * filename,char * const argv[ ],char * const envp[ ]);
可执行程序的装载
- fork两次返回，第一次返回到父进程继续向下执行，第二次是子进程返回到ret_from_fork然后正常返回到用户态。
- execve执行的时候陷入到内核态，用execve中加载的程序把当前正在执行的程序覆盖掉，当系统调用返回的时候也就返回到新的可执行程序起点。
（1）可执行文件开始执行的起点在哪里？如何才能让execve系统调用返回到用户态时执行新程序？
修改int 0x80压入内核堆栈的EIP，通过修改内核堆栈中EIP的值作为新程序的起点。
（2）Linux内核是如何支持多种不同的可执行文件格式
static struct linux_binfmt elf_format//声明一个全局变量 = {
.module = THIS_MODULE,
.load_binary = load_elf_binary,//观察者自动执行
.load_shlib = load_elf_library,
.core_dump = elf_core_dump,
.min_coredump = ELF_EXEC_PAGESIZE,
};
static int __iit init_elf_binfmt(void)
{n
register_binfmt(&elf_format);//把变量注册进内核链表,在链表里查找文件的格式
return 0;
}
（3）动态链接
- 可执行程序需要依赖动态链接库，而这个动态链接库可能会依赖其他的库，这样形成了一个关系图——动态链接库会生成依赖树。
- 依赖动态链接器进行加载库并进行解析（这就是一个图的遍历），装载所有需要的动态链接库；之后ld将CPU的控制权交给可执行程序
- 动态链接的过程主要是动态链接器在起作用，而不是内核完成的。
实验过程及截图
使用gdb跟踪sys_execve内核函数的处理过程
1. 开始先更新内核，再用test_exec.c将test.c覆盖掉
2. test.c文件中增加了exec系统调用，Makefile文件中增加了gcc -o hello hello.c -m32 -static
3. 启动内核并验证execv函数
4. 启动gdb调试
先设置sys_execve后，在menuOS里执行系统调用exec，找到第一个断点。
找到第二个断点
给新栈的栈底指针赋值后，找到第三个断点start_thread
new_ip是返回到用户态的第一条指令
退出调试状态后输入redelf -h hello可以查看hello的EIF头部
可执行程序的装载与庄周梦蝶的故事
庄周（调用execve的可执行程序）入睡（调用execve陷入内核），醒来（系统调用execve返回用户态）发现自己是蝴蝶（被execve加载的可执行程序）
浅析动态链接的可执行程序的装载
1. 动态链接的过程中，内核做了什么？
ldd test ldd libfuse.so //可执行程序需要依赖动态链接库，而这个动态链接库可能会依赖其他的库，实际上动态链接库的依赖关系会形成一个图
2. 是由内核负责加载可执行程序依赖的动态链接库吗？
动态链接器负责加载这些库并进行解析当前的可执行文件，装载所有需要的动态链接库，动态链接库的装载过程是一个图的遍历（广度） 装载和链接后ld将CPU的控制权交给可执行程序 动态链接的过程主要由动态链接器完成，并不是内核