2016-04-07
张超《Linux内核分析》MOOC课程http://mooc.study.163.com/course/USTC-1000029000#/info
一、理解编译链接的过程和ELF可执行文件格式
我给出了一个例子：
第一步：先编辑一个hello.c，如下
vi hello.c
#include <stdio.h>
#include <stdlib.h> int main()
{
printf("Hello World!\n");
return ;
}
hello.c
第二步：生成预处理文件hello.cpp（预处理负责把include的文件包含进来及宏替换等工作）
gcc -E -o hello.cpp hello.c -m32
vi hello.cpp （查看一下hello.cpp的内容，但是太多，这里就不显示了）
第三步：编译成汇编代码hello.s
gcc -x cpp-output -S -o hello.s hello.cpp -m32
vi hello.s （查看一下hello.s的内容，如下所示）
.file "hello.c"
.section .rodata
.LC0:
.string "Hello World!"
.text
.globl main
.type main, @function
main:
.LFB2:
.cfi_startproc
pushl %ebp
.cfi_def_cfa_offset
.cfi_offset , -
movl %esp, %ebp
.cfi_def_cfa_register
andl $-, %esp
subl $, %esp
movl $.LC0, (%esp)
call puts
movl $, %eax
leave
.cfi_restore
.cfi_def_cfa ,
ret
.cfi_endproc
.LFE2:
.size main, .-main
.ident "GCC: (Ubuntu 4.8.4-2ubuntu1~14.04.1) 4.8.4"
.section .note.GNU-stack,"",@progbits
hello.s
第四步：编译成目标代码，得到二进制文件hello.o，（该文件中有机器指令，但不能在机器上直接运行）
gcc -x assembler -c hello.s -o hello.o -m32
vi hello.o （查看一下hello.o的内容，结果是乱码）
第五步：链接成可执行文件hello，（它是二进制文件）
gcc -o hello hello.o -m32
vi hello（查看一下hello，发现除了几个英文标示符可见，其他都是乱码文件，不过开头有ELF）
第六步：运行一下
./hello
其实：我们可以用一个命令直接只生成可执行文件hello，并运行
gcc -o hello hello.c
这里，hello和hello.o都是ELF格式的文件。
而这样编译出来的hello是使用的共享库。
我们也可以静态编译，（是完全把所有需要执行所依赖的东西放到程序内部）
gcc -o hello.static hello.o -m32 -static
hello.static 也是ELF格式文件
运行一下hello.static
./hello.static
ls -l （查看一下各个文件）
发现hello.static （733298）比 hello （7336）大的多。
静态链接于动态链接：
- 静态链接方式于动态链接方式
- 静态链接方式：在程序运行之前完成所有的组装工作，生成一个可执行的目标文件
- 动态链接方式：在程序已经为了执行被装载入内存之后完成链接工作，并且在内存中一般只保留该编译单元的一份拷贝
2.静态链接库（.a(Linux下) .lib(Windows下)）与动态链接库（.so(Linux下) .dll(Windows下)）
静态链接库与动态链接库都是共享代码的方式。如果采用静态链接库，则程序把所有执行需要所依赖的东西都加载到可执行文件中了。但若是使用动态库，则不必被包含在最终执行的文件中，可执行文件执行时可以“动态”的引用和卸载这个与可执行程序独立的动态库文件。
简单的说，静态库和应用程序编译在一起了，在任何情况下都能运行，而动态库是动态链接，顾名思义就是在应用程序启动的时候再会链接的，所以，当用户的系统上没有该动态库时，应用程序就会运行失败。
3.静态库于动态库的特点
静态库：代码的装载速度快，执行速度也快，因为编译时它只会把你所需要的那部分链接进去，应用程序相对较大。但是如果没有多个应用程序的话，会被装载多次，浪费内存。
动态库：
共享：多个应用程序可以使用同一个动态库，启动多个应用程序的时候，只需要将动态库加载到内存一次就好。
开发模块好：要求设计者对功能划分的比较好。
4.认识动态链接库
动态链接库是相对静态链接库而言的。所谓的静态链接库只把要调用的函数或过程链接到可执行文件中，成为可执行文件的一部分。换句话说，函数和过程的代码就在程序的可执行文件中，该文件包含了运行时所需的全部代码。当多个程序都调用相同函数时，内存中就会存在这个函数的多个拷贝，这样就浪费了宝贵的内存资源，而动态链接所调用的函数代码并没有被拷贝到应用程序的可执行文件中去，而是仅仅在其中加入了所调用函数的描述信息（往往是一些重定位信息）。仅当应用程序被装入内存开始运行时，在系统的管理下，才在应用程序与相应的动态库之间建立链接关系。当要执行所调用的动态链接库中的函数时，根据链接产生的重定位信息，系统下转去执行状态链接库中相应的函数代码。一般情况下，如果一个应用程序使用了动态链接库，系统保证内存只有动态库的一份复制品。
动态链接库的两种链接方法：
1）装载时动态链接（Load-time Dynamic Linking）：这种方法的前提是在编译之前已经明确知道要调用的动态库的哪些函数，编译时在目标文件中只保留必要的链接信息，而不含动态库函数代码；当程序执行时，调用函数的时候利用链接信息加载动态库函数代码并在内存中将其链接入调用程序的执行空间中（全部函数加载进内存），其主要目的是便于代码共享。（动态加载程序，处在加载阶段，主要为了共享代码，共享代码内存）
2）运行时动态链接（Run-time Dynamic Linking）：这种方式是指在编译之前并不知道将会调用哪些动态库函数，完全是在运行过程中根据需要决定应调用哪个函数，将其加载到内存中（只加载调用的函数进内存）；并标识内存地址，其他程序也可以使用该程序，并获得动态库函数的入口地址。（动态库在内存中只存在一份，处在运行阶段）
要想理解一个进程是怎样执行的，一个可执行程序是如何加载成进程的？我们这时需要知道可执行文件的内部是什么？
ELF目标文件格式：ELF（Executable And Linkable Format）
-
ELF文件格式--（中文翻译版本）
#define EI_NIDENT 16 typedef struct {
unsigned char e_ident[EI_NIDENT];
Elf32_Half e_type;
Elf32_Half e_machine;
Elf32_Word e_version;
Elf32_Addr e_entry;
Elf32_Off e_phoff;
Elf32_Off e_shoff;
Elf32_Word e_flags;
Elf32_Half e_ehsize;
Elf32_Half e_phentsize;
Elf32_Half e_phnum;
Elf32_Half e_shentsize;
Elf32_Half e_shnum;
Elf32_Half e_shstrndx;
} Elf32_Ehdr;ELF Header
- 查看ELF文件的头部（hello）
readlf -h hello
- 查看该ELF所依赖的共享库（过程及结果如下图所示）
ldd hello
readelf -d （也可以看依赖的so文件）
常见的目标文件的格式有如下：
A.out 是最古老的目标文件格式。 现在用的最多的PE（Windows下用的最多的）、ELF（Linux下用的最多的）
目标文件我们一般也叫ABI（应用程序二进制接口）
实际上在目标文件中它已经是二进制兼容（指目标文件已经是适应到某一个CPU体系上的二进制指令）
比如x86上的可执行文件链接成ARM上的可执行文件肯定是不行的
ELF格式的文件中有三种主要的目标文件
- 可重定位（relocatable）文件保存着代码和适当的数据，用来和其他的object文件一起来创建一个可执行文件或是一个共享文件（主要是 .o 文件）
- 一个可执行（executable）文件保存着一个用来执行的程序；该文件指出了exec(BA_OS)如何来创建序进程映像。
- 一个共享object文件保存这代码和合适的数据，用来被下面的两个链接器链接。第一个连接编译器（请查看ld(SD_CMD)），也可以和其他可重定位和共享object文件来创建他的object。第二是动态链接器，联合一个可执行文件和其他的共享object文件来创建一个进程映像。（主要是 .so 文件）
静态链接的ELF可执行文件于进程的地址空间：
对于32位的x86来讲，进程是4G的进程地址空间，最上面1G是内核用的，下面3G是用户态。0xc000000之上是内核，下面是用户态可访问。
默认进程是从0x8048000开始加载，先是头部（大小不固定），还把代码和数据加载到进程的地址空间。
ELF Header 中的Entry point address 即是可执行文件加载到内存中开始执行的第一行代码。（就像上面的程序，他的值是0x8048320）
一般静态链接会将所有代码放在一个代码段，而动态链接的进程会有多个代码段。
二、编程使用exec*库函数加载一个可执行文件
加载可执行程序前的工作：我们需要了解可执行程序的执行环境，一般是通过shell程序来启动一个可执行程序。
当我们执行可执行文件时，即发起了一个系统调用exec时，我们就要知道shell环境位我们准备了哪些执行的上下文环境。
这样我们就可以大概了解一下用户态的执行环境，然后再看一个exec的系统调用，它怎么把一个可执行文件加载在内核里面，又返回到用户它态。
命令行参数和shell 环境，一般我们执行一个程序的shell环境，我们的实验直接使用execve系统调用。
$ls -l /usr/bin 列出/usr/bin下的目录信息
shell本身不限制命令行参数的个数，命令行参数的个数受限于命令本身。
例如， int main(int argc, char * argv[])
又如， int main(int argc, char * argv[], char * envp[])
shell会调用execve将命令行参数和环境参数传递给可执行程序的main函数
int execve(const char * filename, char * const argv[], char * const envp[])
库函数exec*都是execve的封装例程
#include <stdio.h>
#include <stdlib.h>
#include <unistd.h> int main(int argc,char* argv[])
{
int pid;
/*fork another process*/
pid = fork();
if(pid < )
{
/*error occurred*/
fprintf(stderr,"Fork Failed!\n");
exit(-);
}
else if(pid == )
{
/* child process */
execlp("/bin/ls","ls",NULL);
}
else
{
/* parent process */
/* parent will wait for the child to complete */
wait(NULL);
printf("Child Complete\n");
exit();
}
}
命令行参数和环境变量的保存和传递是当我们创建一个子进程时，（fork是复制父进程），然后调用exece系统调用，它把要加载的可执行程序把原来的进程环境给覆盖掉了，覆盖了以后它的用户态堆栈也被清空。
这时命令行参数和环境变量会被压栈。
shell程序 -> execve -> sys_execve 然后在初始化新进程堆栈时拷贝进去。
int execve(const char * filename , char * const argv[] , char * const envp[])
创建了一个新的用户态堆栈的时候，实际上是把命令行参数（argv[]）的内容和环境变量（envp[]）的内容通过指针的方式传递给系统调用内核处理函数的，然后内核处理函数再建一个可执行程序新的用户态堆栈的时候，会把这些拷贝到用户态堆栈，初始化新的可执行程序执行的上下文环境。
先函数调用参数传递，再系统调用参数传递。
装载时动态链接和运行时动态链接举例：
#include <stdio.h> #include "shlibexample.h" #include <dlfcn.h> /*
* Main program
* input : none
* output : none
* return : SUCCESS(0)/FAILURE(-1)
*
*/
int main()
{
printf("This is a Main program!\n");
/* Use Shared Lib */
printf("Calling SharedLibApi() function of libshlibexample.so!\n");
SharedLibApi();
/* Use Dynamical Loading Lib */
void * handle = dlopen("libdllibexample.so",RTLD_NOW);
if(handle == NULL)
{
printf("Open Lib libdllibexample.so Error:%s\n",dlerror());
return FAILURE;
}
int (*func)(void);
char * error;
func = dlsym(handle,"DynamicalLoadingLibApi");
if((error = dlerror()) != NULL)
{
printf("DynamicalLoadingLibApi not found:%s\n",error);
return FAILURE;
}
printf("Calling DynamicalLoadingLibApi() function of libdllibexample.so!\n");
func();
dlclose(handle);
return SUCCESS;
}
main.c
#ifndef _DL_LIB_EXAMPLE_H_
#define _DL_LIB_EXAMPLE_H_ #ifdef __cplusplus
extern "C" {
#endif
/*
* Dynamical Loading Lib API Example
* input : none
* output : none
* return : SUCCESS(0)/FAILURE(-1)
*
*/
int DynamicalLoadingLibApi(); #ifdef __cplusplus
}
#endif
#endif /* _DL_LIB_EXAMPLE_H_ */
dllibexample.h
#include <stdio.h>
#include "dllibexample.h" #define SUCCESS 0
#define FAILURE (-1) /*
* Dynamical Loading Lib API Example
* input : none
* output : none
* return : SUCCESS(0)/FAILURE(-1)
*
*/
int DynamicalLoadingLibApi()
{
printf("This is a Dynamical Loading libary!\n");
return SUCCESS;
}
dllibexample.c
#ifndef _SH_LIB_EXAMPLE_H_
#define _SH_LIB_EXAMPLE_H_ #define SUCCESS 0
#define FAILURE (-1) #ifdef __cplusplus
extern "C" {
#endif
/*
* Shared Lib API Example
* input : none
* output : none
* return : SUCCESS(0)/FAILURE(-1)
*
*/
int SharedLibApi(); #ifdef __cplusplus
}
#endif
#endif /* _SH_LIB_EXAMPLE_H_ */
shlibexample.h
#include <stdio.h>
#include "shlibexample.h" /*
* Shared Lib API Example
* input : none
* output : none
* return : SUCCESS(0)/FAILURE(-1)
*
*/
int SharedLibApi()
{
printf("This is a shared libary!\n");
return SUCCESS;
}
shlibexample.c
编译成libshlibexample.so
gcc -shared shlibexample.c -o libshlibexample.so -m32
编译成libdllibexample.so
gcc -shared dllibexample.c -o libdllibexample.so -m32
分别以共享库和动态加载共享库的方式使用libshlibexample.so文件和libdllibexample.so文件
编译main时，注意这里只提供shlibexample的-L（库对应的接口头文件所在的目录），和-l（库名，如libshlibexample.so去掉lib和.so的部分）
并没有提供dllibexample的相关信息，只是指名了-dll
gcc main.c -o main -L ~/my/c/SharedLibDynamicLink -lshlibexample -ldl -m32 （其中 ~/my/c/SharedLibDynamicLink 是我的这几个文件所在的路径）
export LD_LIBRARY_PATH=$PWD （将当前目录加入默认路径，否则main找不到依赖的库文件，当然也可以以将库文件copy到默认路径下）
./main
运行结果如下：
三、可执行程序的装载
sys_execve内部会解析可执行文件格式。在 /linux-3.18.6/fs/exec.c
1604SYSCALL_DEFINE3(execve,
const char __user *, filename,
const char __user *const __user *, argv,
const char __user *const __user *, envp)
{
return do_execve(getname(filename), argv, envp);
}
1549int do_execve(struct filename *filename,
const char __user *const __user *__argv,
const char __user *const __user *__envp)
{
struct user_arg_ptr argv = { .ptr.native = __argv };
struct user_arg_ptr envp = { .ptr.native = __envp };
return do_execve_common(filename, argv, envp);
}
do_execve
do_execve -> do_execve_common -> exec_binprm
1549int do_execve(struct filename *filename,
const char __user *const __user *__argv,
const char __user *const __user *__envp)
{
struct user_arg_ptr argv = { .ptr.native = __argv };
struct user_arg_ptr envp = { .ptr.native = __envp };
return do_execve_common(filename, argv, envp);
}
do_execve
/*
1428 * sys_execve() executes a new program.
1429 */static int do_execve_common(struct filename *filename,
struct user_arg_ptr argv,
struct user_arg_ptr envp)
{
struct linux_binprm *bprm;
struct file *file;
struct files_struct *displaced;
int retval; if (IS_ERR(filename))
return PTR_ERR(filename); /*
1443 * We move the actual failure in case of RLIMIT_NPROC excess from
1444 * set*uid() to execve() because too many poorly written programs
1445 * don't check setuid() return code. Here we additionally recheck
1446 * whether NPROC limit is still exceeded.
1447 */
if ((current->flags & PF_NPROC_EXCEEDED) &&
atomic_read(¤t_user()->processes) > rlimit(RLIMIT_NPROC)) {
retval = -EAGAIN;
goto out_ret;
} /* We're below the limit (still or again), so we don't want to make
1455 * further execve() calls fail. */
current->flags &= ~PF_NPROC_EXCEEDED; retval = unshare_files(&displaced);
if (retval)
goto out_ret; retval = -ENOMEM;
bprm = kzalloc(sizeof(*bprm), GFP_KERNEL);
if (!bprm)
goto out_files; retval = prepare_bprm_creds(bprm);
if (retval)
goto out_free; check_unsafe_exec(bprm);
current->in_execve = ; file = do_open_exec(filename);
retval = PTR_ERR(file);
if (IS_ERR(file))
goto out_unmark; sched_exec(); bprm->file = file;
bprm->filename = bprm->interp = filename->name; retval = bprm_mm_init(bprm);
if (retval)
goto out_unmark; bprm->argc = count(argv, MAX_ARG_STRINGS);
if ((retval = bprm->argc) < )
goto out; bprm->envc = count(envp, MAX_ARG_STRINGS);
if ((retval = bprm->envc) < )
goto out; retval = prepare_binprm(bprm);
if (retval < )
goto out; retval = copy_strings_kernel(, &bprm->filename, bprm);
if (retval < )
goto out; bprm->exec = bprm->p;
retval = copy_strings(bprm->envc, envp, bprm);
if (retval < )
goto out; retval = copy_strings(bprm->argc, argv, bprm);
if (retval < )
goto out; retval = exec_binprm(bprm);
if (retval < )
goto out; /* execve succeeded */
current->fs->in_exec = ;
current->in_execve = ;
acct_update_integrals(current);
task_numa_free(current);
free_bprm(bprm);
putname(filename);
if (displaced)
put_files_struct(displaced);
return retval;
out:
if (bprm->mm) {
acct_arg_size(bprm, );
mmput(bprm->mm);
} 1534out_unmark:
current->fs->in_exec = ;
current->in_execve = ; 1538out_free:
free_bprm(bprm); 1541out_files:
if (displaced)
reset_files_struct(displaced);
1544out_ret:
putname(filename);
return retval;
}
do_execve_common
1405static int exec_binprm(struct linux_binprm *bprm)
{
pid_t old_pid, old_vpid;
int ret; /* Need to fetch pid before load_binary changes it */
old_pid = current->pid;
rcu_read_lock();
old_vpid = task_pid_nr_ns(current, task_active_pid_ns(current->parent));
rcu_read_unlock(); ret = search_binary_handler(bprm);
if (ret >= ) {
audit_bprm(bprm);
trace_sched_process_exec(current, old_pid, bprm);
ptrace_event(PTRACE_EVENT_EXEC, old_vpid);
proc_exec_connector(current);
}
exec_binprm
search_binary_handler符合寻找文件格式对应的解析模板，如下：（对于给定的文件名，根据文件头部信息寻找对应的文件格式处理模块）
/*
1350 * cycle the list of binary formats handler, until one recognizes the image
1351 */int search_binary_handler(struct linux_binprm *bprm)
{
bool need_retry = IS_ENABLED(CONFIG_MODULES);
struct linux_binfmt *fmt;
int retval; /* This allows 4 levels of binfmt rewrites before failing hard. */
if (bprm->recursion_depth > )
return -ELOOP; retval = security_bprm_check(bprm);
if (retval)
return retval; retval = -ENOENT;
retry:
read_lock(&binfmt_lock);
list_for_each_entry(fmt, &formats, lh) {
if (!try_module_get(fmt->module))
continue;
read_unlock(&binfmt_lock);
bprm->recursion_depth++;
retval = fmt->load_binary(bprm);
read_lock(&binfmt_lock);
put_binfmt(fmt);
bprm->recursion_depth--;
if (retval < && !bprm->mm) {
/* we got to flush_old_exec() and failed after it */
read_unlock(&binfmt_lock);
force_sigsegv(SIGSEGV, current);
return retval;
}
if (retval != -ENOEXEC || !bprm->file) {
read_unlock(&binfmt_lock);
return retval;
}
}
read_unlock(&binfmt_lock); if (need_retry) {
if (printable(bprm->buf[]) && printable(bprm->buf[]) &&
printable(bprm->buf[]) && printable(bprm->buf[]))
return retval;
if (request_module("binfmt-%04x", *(ushort *)(bprm->buf + )) < )
return retval;
need_retry = false;
goto retry;
} return retval;
}
1403EXPORT_SYMBOL(search_binary_handler);
search_binary_handler
对于ELF格式的可执行文件fmt->load_binary(bprm); 执行的应该是load_elf_binary其内部是和ELF文件格式解析的部分需要和ELF文件格式标准结合起来阅读。
load_elf_binary在/linux-3.18.6/fs/binfmt_elf.c
Linux内核是如何支持多种不同的可执行文件格式的？ 在 /linux-3.18.6/fs/binfmt_elf.c
elf_format（观察者）和init_elf_binfmt（被观察者），他们是观察者模式。
四、实验，使用gdb跟踪sys_execve内核函数的处理过程
实验步驟
先切换到 LinuxKernel目录下
rm menu -rf //删除menu
git clone https://github.com/mengning/menu.git //下载克隆新的menu
cd menu //切换到menu目录下
mv test_exce.c test.c //把test_exce.c 改成 test.c ，这里是应为Makefile里面用的是test.c
vi test.c //查看一下test.c的内容
vi makefile //查看一下Makefile的内容
make rootfs //
这时候就运行了，结果如下：
我们在打开一个新的终端，在终端里右键，选择打开终端（或水平分割）用2表示新的终端
2 gdb
2 file ../linux-3.18.6/vmlinux
2 target remote:1234
然后我选取了几个断点
2 b sys_execve （可以先停在sys_exceve然后再设置其他断点）
2 b search_bianry_handler
2 b load_elf_binary
2 b start_thread
运行的部分过程如下：
以上实验是静态链接可执行程序。而大部分执行程序是用动态链接，需要用到动态链接库。需要动态链接的可执行文件先加载连接器ld，将cpu控制权交给ld来加载依赖库并完成动态链接。对于静态链接的文件elf_entry是新进程的执行起点。
实际上动态链接库的依赖关系会形成一个图。其实不是由内核负责加载可执行程序依赖的动态链接库的，而是由动态链接器。动态链接库的装载过程是一个图的遍历。装载和链接之后ld将cpu的控制权交给可执行程序。
五、总结
我们通过跟踪以及查看分析代码，执行的流程是：（代码见上面）
sys_execve -> do_execve -> do_execve_common -> exec_binprm -> search_binary_handler -> load_binary ->(对于我们这里的ELF，会跳转到)load_elf_binary （也执行了elf_format）-> start_thread
我们调用execve的可执行程序时，当执行到exceve时，系统调用exceve陷入内核，这时会创建一个新的用户态堆栈，实际是把命令行参数的内容和环境变量的内容通过指针的方式传递给系统调用内核处理函数的，然后内核处理函数在创建可执行程序新的用户态堆栈的时候，会把这些拷贝到用户态堆栈初始化新的可执行程序的执行上下文环境（先函数调用参数传递，再系统调用参数传递）。这时就加载了新的可执行程序。系统调用exceve返回用户态的时候，就变成了被exceve加载的可执行程序。