zoukankan      html  css  js  c++  java
  • Linux内核分析作业 NO.7

    可执行程序的装载

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

    实验:Linux内核如何装载和启动一个可执行程序

    首先,按照老流程,我们进入LinuxKernel,删除menu,再拷贝menu

    然后我们进入menu,用test_exec和test.c中的一个覆盖另一个

    我们打开test.c查看代码

    和exec有关的部分,其中引入了hello

    打开hello,发现hello就是我们熟悉的输出Hello World的程序

    再打开Makefile,观察和修改编译的过程,光标指向的地方是静态编译hello.c的指令

    修改代码,生成根文件树,使执行exec的时候可以做到自动加载

    运行程序,我们看到了MenuOS中exec这个选项,执行。

    比起fork的结果,exec的输出中多了一个Hello World

    接下来又是熟悉的设置断点的工作了

    运行gdb,加载符号表,输入端口号

    设置三个断点,分别在sys_execve,load_elf_binary,start_thread

    运行。。。

    输入list,就能看到运行到哪了

    进入,一步一步的执行

    new_ip:返回到用户态的第一条指令的地址

    对照一下,地址是一样的哟~

    运行运行运行。。。

    结束了

    总结:

    这一章我们学习的东西主要分三块:

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

    2.可执行程序、共享库和动态链接

    3.可执行程序的装载

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

    可执行程序是怎么来的?

    可执行文件形成的过程:

    c代码通过编译器编译成汇编代码,又通过汇编器汇编成后缀为.o的目标代码,通过链接变成可执行文件,然后加载进内存,执行

    以hello.c为例:

    shiyanlou:~/ $ cd Code                                                [9:27:05]
    shiyanlou:Code/ $ vi hello.c                                          [9:27:14]
    shiyanlou:Code/ $ gcc -E -o hello.cpp hello.c -m32                    [9:34:55]
    shiyanlou:Code/ $ vi hello.cpp                                        [9:35:04]
    shiyanlou:Code/ $ gcc -x cpp-output -S -o hello.s hello.cpp -m32      [9:35:21]
    shiyanlou:Code/ $ vi hello.s                                          [9:35:28]
    shiyanlou:Code/ $ gcc -x assembler -c hello.s -o hello.o -m32         [9:35:58]
    shiyanlou:Code/ $ vi hello.o                                          [9:38:44]
    shiyanlou:Code/ $ gcc -o hello hello.o -m32                           [9:39:37]
    shiyanlou:Code/ $ vi hello                                            [9:39:44]
    shiyanlou:Code/ $ gcc -o hello.static hello.o -m32 -static            [9:40:21]
    shiyanlou:Code/ $ ls -l                                               [9:41:13]
    -rwxrwxr-x 1 shiyanlou shiyanlou   7292  3u6708 23 09:39 hello
    -rw-rw-r-- 1 shiyanlou shiyanlou     64  3u6708 23 09:30 hello.c
    -rw-rw-r-- 1 shiyanlou shiyanlou  17302  3u6708 23 09:35 hello.cpp
    -rw-rw-r-- 1 shiyanlou shiyanlou   1020  3u6708 23 09:38 hello.o
    -rw-rw-r-- 1 shiyanlou shiyanlou    470  3u6708 23 09:35 hello.s
    -rwxrwxr-x 1 shiyanlou shiyanlou 733254  3u6708 23 09:41 hello.static

    其中需要注意的是:

    (1)

    shiyanlou:Code/ $ gcc -E -o hello.cpp hello.c -m32

    只是对c程序的预处理,预处理负责把include的文件包含进来及宏替代等工作

    (2)后面的hello.o和hello都是ELF格式的文件,hello是调用共享库的

    (3)

    shiyanlou:Code/ $ gcc -o hello.static hello.o -m32 -static 

    .static:静态编译

    (4)每句话后面的-m32,是由于运行的系统是64位系统,输入的语句却是32位系统中的语句

    目标文件的格式

    有几种格式如下:

    其中PE用于Windows系统,ELF用于Linux系统

    之前涉及到的.o,就是一种目标文件

    ABI:应用程序二进制接口

    二进制兼容的格式就是指:目标文件已经适应了某种CPU中的二进制指令

    ELF目标文件有三种:可重定位文件,可执行文件,共享目标文件

    格式:

    目标文件参与程序的联接(创建一个程序)和程序的执行(运行一个程序)

    阅读ELF文件的头部:

    shiyanlou:Code/ $ readelf -h hello

    查看该ELF文件依赖的共享库

    shiyanlou:sharelib/ $ ldd main                                       [21:25:56]
        linux-gate.so.1 =>  (0xf774e000) // 这个是vdso - virtual DSO:dynamically shared object,并不存在这个共享库文件,它是内核的一部分,为了解决libc与新版本内核的系统调用不同步的问题,linux-gate.so.1里封装的系统调用与内核支持的系统调用完全匹配,因为它就是内核的一部分嘛。而libc里封装的系统调用与内核并不完全一致,因为它们各自都在版本更新。
        libshlibexample.so => /home/shiyanlou/LinuxKernel/sharelib/libshlibexample.so (0xf7749000)
        libdl.so.2 => /lib32/libdl.so.2 (0xf7734000)
        libc.so.6 => /lib32/libc.so.6 (0xf7588000)
        /lib/ld-linux.so.2 (0xf774f000)
    shiyanlou:sharelib/ $ ldd /lib32/libc.so.6                         [21:37:00]
        /lib/ld-linux.so.2 (0xf779e000)
        linux-gate.so.1 =>  (0xf779d000)
    # readelf -d 也可以看依赖的so文件
    shiyanlou:sharelib/ $ readelf -d main                              [21:28:04]
    Dynamic section at offset 0xf04 contains 26 entries:
     0x00000001 (NEEDED)                     共享库:[libshlibexample.so]
     0x00000001 (NEEDED)                     共享库:[libdl.so.2]
     0x00000001 (NEEDED)                     共享库:[libc.so.6]
     0x0000000c (INIT)                       0x80484f0
     0x0000000d (FINI)                       0x8048804
     0x00000019 (INIT_ARRAY)                 0x8049ef8

    入口地址:Entry Point Address,一个程序的起点

    当创建或增加一个进程映像时,系统在理论上将拷贝一个文件的段到一个虚拟的内存段。可执行文件的格式与进程地址空间有一个映射关系。

    静态链接的ELF可执行文件与进程的地址空间

    其实地址默认为:0x8048000,但这不是真正的起始地址。

    启动一个刚加载到可执行文件的进程时,可执行文件加载到内存中开始执行的第一行代码

    一般静态链接会将所有代码放在一个代码段,能把整个程序执行完,所有的过程都设定好了

    动态链接的进程会有多个代码段,更复杂

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

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

    一般通过shell程序来启动一个可执行程序

    shell程序-->execve-->sys_execve

    然后在初始化新程序堆栈时拷贝进去:先函数调用参数传递,再系统调用参数传递

    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<0) 
              { 
                  /* error occurred */
                  fprintf(stderr,"Fork Failed!");
                  exit(-1);
              } 
              else if (pid==0) 
              {
                  /*   child process   */
                  execlp("/bin/ls","ls",NULL);
              } 
              else 
              {  
                  /*     parent process  */
                  /* parent will wait for the child to complete*/
                  wait(NULL);
                  printf("Child Complete!");
                  exit(0);
              }
          }

          命令行参数和环境串都放在用户态堆栈中

    装载时动态链接和运行时动态链接应用举例

    动态链接分为可执行程序装载时动态链接和运行时动态链接,如下代码演示了这两种动态链接。

    准备.so文件

    shlibexample.h (1.3 KB) - Interface of Shared Lib Example

    shlibexample.c (1.2 KB) - Implement of Shared Lib Example

    编译成libshlibexample.so文件

    $ gcc -shared shlibexample.c -o libshlibexample.so -m32

    dllibexample.h (1.3 KB) - Interface of Dynamical Loading Lib Example

    dllibexample.c (1.3 KB) - Implement of Dynamical Loading Lib Example

    编译成libdllibexample.so文件

    $ gcc -shared dllibexample.c -o libdllibexample.so -m32

    分别以共享库和动态加载共享库的方式使用libshlibexample.so文件和libdllibexample.so文件

    main.c  (1.9 KB) - Main program

    编译main,注意这里只提供shlibexample的-L(库对应的接口头文件所在目录)和-l(库名,如libshlibexample.so去掉lib和.so的部分),并没有提供dllibexample的相关信息,只是指明了-ldl

    $ gcc main.c -o main -L/path/to/your/dir -lshlibexample -ldl -m32
    $ export LD_LIBRARY_PATH=$PWD #将当前目录加入默认路径,否则main找不到依赖的库文件,当然也可以将库文件copy到默认路径下。
    $ ./main
    This is a Main program!
    Calling SharedLibApi() function of libshlibexample.so!
    This is a shared libary!
    Calling DynamicalLoadingLibApi() function of libdllibexample.so!
    This is a Dynamical Loading libary!

     装载时动态链接:生成共享库文件,生成动态加载文件

    有两种方法:

    (1)在装载可执行程序时完成动态链接的过程

    (2)在程序执行过程中由程序自身来加载共享库

    3.可执行程序的装载

    execve和fork都是特殊一点的系统调用

    复习:fork要返回两次,子程序是从ret_from_fork开始执行然后返回用户态

    而execve独特的地方在于:陷入内核态,把当前进程的可执行程序覆盖掉,返回的已经是新的可执行程序

    sys_execve内核处理过程

    根据文件头部信息寻找对应的文件格式(这里就是ELF)处理模块

    命令行参数和shell环境,一般我们执行一个程序的Shell环境,我们的实验直接使用execve系统调用。

    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的封装例程

    sys_execve内部会解析可执行文件格式

    do_execve -> do_execve_common -> exec_binprm

    search_binary_handler符合寻找文件格式对应的解析模块,如下:

    1369    list_for_each_entry(fmt, &formats, lh) {
    
    1370        if (!try_module_get(fmt->module))
    
    1371            continue;
    
    1372        read_unlock(&binfmt_lock);
    
    1373        bprm->recursion_depth++;
    
    1374        retval = fmt->load_binary(bprm);
    
    1375        read_lock(&binfmt_lock);

    fmt:链表中的一个节点

    对于ELF格式的可执行文件fmt->load_binary(bprm);执行的应该是load_elf_binary其内部是和ELF文件格式解析的部分需要和ELF文件格式标准结合起来阅读

    关键词:观察者模式  多台  发布订阅架构

    82static struct linux_binfmt elf_format = {
    
    83  .module     = THIS_MODULE,
    
    84  .load_binary    = load_elf_binary,
    
    85  .load_shlib = load_elf_library,
    
    86  .core_dump  = elf_core_dump,
    
    87  .min_coredump   = ELF_EXEC_PAGESIZE,
    
    88};
    2198static int __init init_elf_binfmt(void)
    
    2199{
    
    2200    register_binfmt(&elf_format);
    
    2201    return 0;
    
    2202}

    execve系统调用返回到用户态从哪里开始执行?

    通过修改内核堆栈中的EIP值作为新程序的起点

    sys_execve系统调用处理过程

    ELF可执行文件会被默认映射到0x8048000这个地址

    需要动态链接的可执行文件去加载链接器ld

    elf_entry:指向可执行文件里规定的头部(main函数对应的位置);如果是动态链接,就是动态链接器的起点(用户态的起点),将cpu控制权交给ld来加载依赖库并完成动态链接

    start_thread:把我们返回用户态的位置从0x8048000的下一条变成我们规定的entry的位置

    庄生梦蝶 —— 醒来迷惑是庄周梦见了蝴蝶还是蝴蝶梦见了庄周?

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

    庄子和蝴蝶:你可以装载我,我可以装载你

    修改int 0x80压入内核堆栈的EIP

    load_elf_binary ->  start_thread

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

    大多程序都需要依赖动态链接库

    可以关注ELF格式中的.interp和.dynamic

    实际上动态链接库的依赖关系会形成一个图,动态链接装载的过程是一个图的广度遍历

    装载和链接后ld将cpu的控制权交给可执行程序

    动态链接的过程主要不是内核而是由动态链接器来完成的

    To tell the turth,虽然我是这周的课题负责人,但是对课题的理解还是有限的,好几个视频我都懵逼了,恩,求高分。

  • 相关阅读:
    软件设计原则
    UML 类图
    Lambda 四大内置核心函数式接口
    Lambda 表达式简介
    vuex源码解析及简单实现
    websocket
    module.export / require 和 export / import
    关于form表单提交时required属性失效的问题
    更改mysql引擎后无法建立外键(navicat)
    关于Android studio SDK的安装与配置
  • 原文地址:https://www.cnblogs.com/javablack/p/5356215.html
Copyright © 2011-2022 走看看