《Linux内核分析》第七周 可执行程序的装载

时间:2024-10-07 11:05:20

【刘蔚然 原创作品转载请注明出处 《Linux内核分析》MOOC课程http://mooc.study.163.com/course/USTC-1000029000

WEEK SEVEN(4.4——4.10)可执行程序的装载

SECTION 1 预处理、编译、链接和目标文件的格式

1.可执行程序如何产生的?

《Linux内核分析》第七周 可执行程序的装载

  1. 编译器预处理(把include的文件包含进来,并且完成宏的替换)

     gcc -E -o XX.cpp XX.c (-m32)//.cpp是预处理文件
  2. 汇编器编译成汇编代码

     gcc -x cpp-output -S -o hello.s hello.cpp (-m32)//.s是汇编代码
  3. 汇编代码编译成二进制目标文件(不可读,含有部分机器代码但不可执行)

     gcc -x assembler -c hello.s -o hello.o (-m32)
  4. 链接成可执行文件

     gcc -o hello.static hello.c (-m32) -static
  5. 补充:

    1. hello和hello.o都是ELF文件
    2. .static文件会将所有用到C库文件都放到这一个可执行程序中(所以占用空间比较多)

2.目标文件格式ELF

  1. .out是最古老的可执行文件,目前Windows系统上多是PE,Linux系统上多是ELF

    • 《Linux内核分析》第七周 可执行程序的装载
  2. ELF文件已经是适应到某一种CPU体系结构的二进制兼容文件了

  3. 目标文件三种形式

    1. 可重定位文件(用来和其他object文件一起创建下面两种文件)——.o文件
    2. 可执行文件(指出了应该从哪里开始执行)
    3. 共享文件(主要是.so文件,用来被链接编辑器和动态链接器链接)
  4. ELF格式

    • 《Linux内核分析》第七周 可执行程序的装载

    • 解释:

      • 左半边是ELF格式,右半边是执行时候的格式;
      • 其中,ELF头描述了该文件的组织情况,程序投标告诉系统如何创建一个进程的内存映像,section头表包含了描述文件sections的信息
    • 《Linux内核分析》第七周 可执行程序的装载

    • 解释:

      • 当系统要执行一个文件的时候,理论上讲,他会把程序段拷贝到虚拟内存中某个段
    • 《Linux内核分析》第七周 可执行程序的装载

    • 解释

      • entry代表(刚加载过新的可执行文件之后的)程序的入口地址(头部之后是代码和数据,进程的地址空间是4G,上面的1G是内核用,下面的3G是程序使用)默认的ELF头加载地址是0x8048000,头部大概要到0x48100处或者0x483000处,也就是可执行文件加载到内存之后执行的第一条代码地址
      • 一般静态链接会将所有代码放在一个代码段;动态链接的进程会有多个代码段

可执行文件、共享库和动态链接

1.装载可执行程序之前的工作

  1. 可执行程序的执行环境

    • 一般我们执行一个程序的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[ ]);
    • 例子:

        1.#include <stdio.h>
      2.#include <stdlib.h>
      3.#include <unistd.h>
      4.int main(int argc, char * argv[])//这里不是完整的命令函数,没有写命令行参数
      5.{
      6. int pid;
      7. /* fork another process *///避免原有的shell程序被覆盖掉
      8. pid = fork();
      9. if (pid<0)
      10. {
      11. /* error occurred */
      12. fprintf(stderr,"Fork Failed!");
      13. exit(-1);
      14. }
      15. else if (pid==0)
      16. {
      17. /* child process */
      18. execlp("/bin/ls","ls",NULL);//以ls命令为例
      19. }
      20. else
      21. {
      22. /* parent process */
      23. /* parent will wait for the child to complete*/
      24. wait(NULL);
      25. printf("Child Complete!");
      26. exit(0);
      27. }
      28.}
  2. 命令行参数和环境串都放在用户态堆栈中

    • 《Linux内核分析》第七周 可执行程序的装载

    • fork子进程的时候完全复制了父进程;调用exec的时候,要加载的可执行程序把原来的进程环境覆盖掉,用户态堆栈也被清空

    • 命令行参数和环境变量进入新程序的堆栈:把环境变量和命令行参数压栈(如上图),也就相当于main函数启动

    • shell程序-->execve-->sys_execve,然后在初始化新程序堆栈的时候拷贝进去

    • 先传递函数调用参数,再传递系统调用参数

2.装载时动态链接和运行时动态链接应用

  1. 动态链接分为可执行程序装载时动态链接和运行时动态链接(大部分使用前者);

  2. 举例1(共享库的动态链接)

    • 准备.so文件(在Linux下动态链接文件格式,在Windows中是.dll)

        #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_ */
      /*------------------------------------------------------*/ #include <stdio.h>
      #include "shlibexample.h" int SharedLibApi()
      {
      printf("This is a shared libary!\n");
      return SUCCESS;
      }/* _SH_LIB_EXAMPLE_C_ */
    • 编译成.so文件

        $ gcc -shared shlibexample.c -o libshlibexample.so -m32
  3. 举例2(动态加载库)(与上面的方式一样)

     #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_ */
    /*------------------------------------------------------*/ #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;
    }
  4. 比较

     #include <stdio.h>
    
     #include "shlibexample.h" //只include了共享库
    
     #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();//可以直接调用,因为include了这个库的接口
    /* 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);//与dlopen函数配合,用于卸载链接库
    return SUCCESS;
    }
    • 解释

    • 编译

        1.$ gcc main.c -o main -L/path/to/your/dir -lshlibexample -ldl -m32  #这里只提供shlibexample的-L(库对应的接口头文件所在目录,也就是path to your dir)和-l(库名,如libshlibexample.so去掉lib和.so的部分),并没有提供dllibexample的相关信息,只是指明了-ldl
      2.$ export LD_LIBRARY_PATH=$PWD #将当前目录加入默认路径,否则main找不到依赖的库文件,当然也可以将库文件copy到默认路径下。
      3.$ ./main
      4.This is a Main program!
      5.Calling SharedLibApi() function of libshlibexample.so!
      6.This is a shared libary!
      7.Calling DynamicalLoadingLibApi() function of libdllibexample.so!
      8.This is a Dynamical Loading libary!

可执行程序装载

1.可执行程序装载的关键问题

  1. execve与fork是比较特殊的系统调用

    • execve用它加载的可执行文件把当前的进程覆盖掉,返回之后就不是原来的程序而是新的可执行程序起点;
    • fork函数的返回点ret_from_fork是用户态起点
  2. sys_execve内核处理过程

    • do_execve -> do_execve_common -> exec_binprm

    • 最后,根据文件头部信息寻找对应的文件格式处理模块

        1369    list_for_each_entry(fmt, &formats, lh) {//在链表中寻找可以处理这种格式(比如ELF)的模块
      1370 if (!try_module_get(fmt->module))
      1371 continue;
      1372 read_unlock(&binfmt_lock);
      1373 bprm->recursion_depth++;
      1374 retval = fmt->load_binary(bprm);//对于ELF格式的可执行文件fmt->load_binary(bprm);执行的应该是load_elf_binary其内部是和ELF文件格式解析的部分需要和ELF文件格式标准结合起来阅读
      1375 read_lock(&binfmt_lock);
  3. Linux内核是如何支持多种不同的可执行文件格式的?

     1.82static struct linux_binfmt elf_format = {//elf_format结构体
    2.83 .module = THIS_MODULE,
    3.84 .load_binary = load_elf_binary,
    4.85 .load_shlib = load_elf_library,
    5.86 .core_dump = elf_core_dump,
    6.87 .min_coredump = ELF_EXEC_PAGESIZE,
    7.88}; 1.2198static int __init init_elf_binfmt(void)
    2.2199{
    3.2200 register_binfmt(&elf_format);//把elf_format变量注册到fmt链表中
    4.2201 return 0;
    5.2202}

【庄周梦蝶——庄周(调用execve的可执行程序)入睡(调用execve陷入内核),醒来(系统调用execve返回用户态)发现自己是蝴蝶(被execve加载的可执行程序)】

  1. load_elf_binary调用start_thread函数

    • 《Linux内核分析》第七周 可执行程序的装载

    • 解释:

      • struct pt_regs *regs就是内核堆栈栈底的部分
      • 发生中断的时候,esp和ip都进行压栈
      • 通过修改内核堆栈中EIP的值(也就是把压入栈中的值用new_ip替换)作为新程序的起点
      • 那么,new_ip从何而来?
        • 《Linux内核分析》第七周 可执行程序的装载

        • 这里的elf_entry就是静态链接的时候可执行文件里面头部定义的entry

      • 动态链接的过程更加复杂一点

2.sys_execve内部处理过程

  1. 《Linux内核分析》第七周 可执行程序的装载

    《Linux内核分析》第七周 可执行程序的装载

    《Linux内核分析》第七周 可执行程序的装载

    • 先打开file文件,然后找到文件头部,把命令行参数和环境变量copy到结构体中(1505行)
  2. 《Linux内核分析》第七周 可执行程序的装载

    • 1416行是关键代码,即寻找打开的可执行文件处理函数
  3. 《Linux内核分析》第七周 可执行程序的装载

    • 寻找能够解析当前可执行文件的模块
    • 1374行load_binary加载这个模块,它实际调用的是binfmt_elf.c
    • ELF可执行文件默认映射到0x8048000这个地址
  4. 《Linux内核分析》第七周 可执行程序的装载

    • 需要动态链接的可执行文件先加载连接器ld;否则直接把elf文件entry地址赋值给entry即可。
    • start_thread(regs, elf_entry, bprm->p)会将CPU控制权交给ld来加载依赖库并完成动态链接;对于静态链接的文件elf_entry是新程序执行的起点

3.使用gdb跟踪sys_execve内核函数的处理过程

  1. 更新menu内核

    • 《Linux内核分析》第七周 可执行程序的装载
  2. 查看test.c文件(shift+G直接到文件尾):可以看到新增加了exec系统调用,其源代码与之前的fork类似

    • 《Linux内核分析》第七周 可执行程序的装载

    • 《Linux内核分析》第七周 可执行程序的装载

  3. 直接e hello.c切换到hello.c

    • 《Linux内核分析》第七周 可执行程序的装载
  4. 查看Makefile,发现增加了gcc -o hello hello.c -m32 -static一句;并且我依照实验视频补充了cp hello ../rootfs以及cp init ../rootfs

    • 《Linux内核分析》第七周 可执行程序的装载
  5. 启动内核并验证execv函数

    • 《Linux内核分析》第七周 可执行程序的装载

    • 《Linux内核分析》第七周 可执行程序的装载

  6. 冻结内核,启动GDB调试

    • 《Linux内核分析》第七周 可执行程序的装载

    • 《Linux内核分析》第七周 可执行程序的装载

  7. 进行调试

    • 先停在sys_execve处,再设置其它断点;按c一路运行下去直到断点sys_execve

    • 《Linux内核分析》第七周 可执行程序的装载

    • 按s跳入函数内单步执行

    • 《Linux内核分析》第七周 可执行程序的装载

    • 《Linux内核分析》第七周 可执行程序的装载

    • 《Linux内核分析》第七周 可执行程序的装载

    • new_ip是返回到用户态的第一条指令

    • 《Linux内核分析》第七周 可执行程序的装载

  8. 退出调试状态,输入redelf -h hello可以查看hello的EIF头部

    • 《Linux内核分析》第七周 可执行程序的装载

4.浅析动态链接的可执行程序的装载

  1. 动态链接的过程中,内核做了什么
    • ldd test
    • 可执行程序需要依赖动态链接库,而这个动态链接库可能会依赖其他的库,这样形成了一个关系图;
    • interpreter:需要依赖动态链接器进行加载这些库并进行解析(这就是一个图的遍历),装载所有需要的动态链接库;之后ld将CPU的控制权交给可执行程序
    • 所以,动态链接的过程主要是动态链接器在起作用,而不是内核