Linux 0.11-execve函数-35

Posted 2022-12-10 热爱编程的大忽悠

Linux 0.11-execve函数-35

• execve函数
• • 读取文件开头 1KB 的数据
  • 解析这 1KB 的数据为 exec 结构
  • 判断是脚本文件还是可执行文件
  • 准备参数空间
  • 设置 eip 和 esp，完成摇身一变
  • 累了吧，休息会
• 转载

---

execve函数

书接上回，上回书咱们说到，进程 1 再次通过 fork 函数创建了进程 2，且进程 2 通过 close 和 open 函数，将 0 号文件描述符指向的标准输入 /dev/tty0 更换为指向 /etc/rc 文件。

void init(void) 
    ...
    if (!(pid=fork())) 
        close(0);
        open("/etc/rc",O_RDONLY,0);
        execve("/bin/sh",argv_rc,envp_rc);
        _exit(2);
    
    ...

此时进程 2 和进程 1 几乎是完全一样的。

接下来进程 2 就将变得不一样了，会通过一个经典的，也是最难理解的 execve 函数调用，使自己摇身一变，成为 /bin/sh 程序继续运行！

我们先打开 execve，开一下它的调用链。

static char * argv_rc[] =  "/bin/sh", NULL ;
static char * envp_rc[] =  "HOME=/", NULL ;

// 调用方
execve("/bin/sh",argv_rc,envp_rc);

// 宏定义
_syscall3(int,execve,const char *,file,char **,argv,char **,envp)

// 通过系统调用进入到这里
EIP = 0x1C
_sys_execve:
    lea EIP(%esp),%eax
    pushl %eax
    call _do_execve
    addl $4,%esp
    ret

// 最终执行的函数
int do_execve(
        unsigned long * eip,
        long tmp,
        char * filename,
        char ** argv,
        char ** envp) 
    ...

我们在 第25回 | 通过 fork 看一次系统调用 已经详细分析了整个调用链中的栈以及参数传递的过程。

所以这里我们就不再赘述，直接把这里的参数传过来的样子写出来。

• eip 调用方触发系统调用时由 CPU 压入栈空间中的 eip 的指针 。
• tmp 是一个无用的占位参数。
• filename 是 “/bin/sh”
• argv 是 “/bin/sh”, NULL
• envp 是 “HOME=/”, NULL

好了，接下来我们看看整个 do_execve 函数，它非常非常长！我先把整个结构列出。

int do_execve(...) 
    // 检查文件类型和权限等
    ...
    // 读取文件的第一块数据到缓冲区
    ...
    // 如果是脚本文件，走这里
    if (脚本文件判断逻辑) 
        ...
    
    // 如果是可执行文件，走这里
    // 一堆校验可执行文件是否能执行的判断
    ...
    // 进程管理结构的调整
    ...
    // 释放进程占有的页面
    ...
    // 调整线性地址空间、参数列表、堆栈地址等
    ...
    // 设置 eip 和 esp，这里是 execve 变身大法的关键！
    eip[0] = ex.a_entry;
    eip[3] = p;
    return 0;
    ...

整理起来的步骤就是。

1 检查文件类型和权限等

2 读取文件的第一块数据到缓冲区

3 脚本文件与可执行文件的判断

4 校验可执行文件是否能执行

5 进程管理结构的调整

6 释放进程占有的页面

7 调整线性地址空间、参数列表、堆栈地址等

8 设置 eip 和 esp，完成摇身一变

如果去掉一些逻辑校验和判断，那核心逻辑就是加载文件、调整内存、开始执行三个步骤，由于这些部分的内容已经非常复杂了，所以我们就去掉那些逻辑校验的部分，直接挑主干逻辑进行讲解，以便带大家认清 execve 的本质。

走你~

读取文件开头 1KB 的数据

先是根据文件名，找到并读取文件里的内容

// exec.c
int do_execve(...) 
    ...
    // 根据文件名 /bin/sh 获取 inode
    struct m_inode * inode = namei(filename);
    // 根据 inode 读取文件第一块数据（1024KB）
    struct buffer_head * bh = bread(inode->i_dev,inode->i_zone[0]);
    ...

很简单，就是读取了文件（/bin/sh）第一个块，也就是 1KB 的数据，

在 第32回 | 加载根文件系统 里说过文件系统的结构，所以代码里 inode -> i_zone[0] 就刚好是文件开头的 1KB 数据。

OK，现在这 1KB 的数据，就已经在内存中了，但还没有解析。

---

解析这 1KB 的数据为 exec 结构

接下来的工作就是解析它，本质上就是按照指定的数据结构来解读罢了。

// exec.cint 
do_execve(...) 
  
  ...  
  struct exec ex = *((struct exec *) bh->b_data);  
  ...

先从刚刚读取文件返回的缓冲头指针中取出数据部分 bh -> data，也就是文件前 1024 个字节，此时还是一段读不懂的二进制数据。

linux 0.11文件格式统一为已经过时的a.out格式,/bin/sh可执行程序对应的文件，其文件前1024个字节为就是a.out格式规定下的文件头信息。

然后按照 exec 这个结构体对其进行解析，它便有了生命。

struct exec 
    // 魔数
    unsigned long a_magic;
    // 代码区长度
    unsigned a_text;
    // 数据区长度
    unsigned a_data;
    // 未初始化数据区长度
    unsigned a_bss;
    // 符号表长度
    unsigned a_syms;
    // 执行开始地址
    unsigned a_entry;
    // 代码重定位信息长度
    unsigned a_trsize;
    // 数据重定位信息长度
    unsigned a_drsize;
;

上面的代码就是 exec 结构体，这是 a.out 格式文件的头部结构，现在的 Linux 已经弃用了这种古老的格式，改用 ELF 格式了，但大体的思想是一致的。

这个结构体里的字段表示什么，等我们用到了再说，你可以先通过我的注释自己体会下。

---

判断是脚本文件还是可执行文件

我们写一个 Linux 脚本文件的时候，通常可以看到前面有这么一坨东西。

#!/bin/sh
#!/usr/bin/python

你有没有想过为什么我们通常可以直接执行这样的文件？其实逻辑就在下面这个代码里。

// exec.c
int do_execve(...) 
    ...
    if ((bh->b_data[0] == '#') && (bh->b_data[1] == '!') 
        ...
    
    brelse(bh);
    ...

可以看到，很简单粗暴地判断前面两个字符是不是 #!，如果是的话，就走脚本文件的执行逻辑。

当然，我们现在的 /bin/sh 是个可执行的二进制文件，不符合这样的条件，所以这个 if 语句里面的内容我们也可以不看了，直接看外面，执行可执行二进制文件的逻辑。

第一步就是 brelse 释放这个缓冲块，因为已经把这个缓冲块内容解析成 exec 结构保存到我们程序的栈空间里了，那么这个缓冲块就可以释放，用于其他读取磁盘时的缓冲区。

这里缓冲块部分知识点联系前面初始化缓冲区部分章节，每个缓冲块大小刚好为1页

不重要，我们继续往下看。

---

准备参数空间

我们执行 /bin/sh 时，还给它传了 argc 和 envp 参数，就是通过下面这一系列代码来实现的。

#define PAGE_SIZE 4096
#define MAX_ARG_PAGES 32

// exec.c
int do_execve(...) 
    ...
    // p = 0x1FFFC = 128K - 4
    unsigned long p = PAGE_SIZE * MAX_ARG_PAGES - 4;
    ...
    // p = 0x1FFF5 = 128K - 4 - 7
    p = copy_strings(envc,envp,page,p,0);
    // p = 0x1FFED = 128K - 4 - 7 - 8
    p = copy_strings(argc,argv,page,p,0);
    ...
    // p = 0x3FFFFED = 64M - 4 - 7 - 8
    p += change_ldt(ex.a_text,page)-MAX_ARG_PAGES*PAGE_SIZE;
    // p = 0x3FFFFD0
    p = (unsigned long) create_tables((char *)p,argc,envc);
    ...
    // 设置栈指针
    eip[3] = p;

准备参数空间的过程，同时也伴随着一个表示地址的 unsigned long p 的计算轨迹。

有点难以理解，别急，我们一点点分析就会恍然大悟。

开头一行计算出的 p 值为

p = 4096 * 32 - 4 = 0x20000 - 4 = 128K - 4

为什么是这个数呢？整个这块讲完你就会知道，这表示参数表，每个进程的参数表大小为 128K，在每个进程地址空间的最末端。

还记得之前的一张图么？

我们说过，每个进程通过不同的局部描述符在线性地址空间中瓜分出不同的空间，一个进程占 64M，我们单独把这部分表达出来。

参数表为 128K，就表示每个进程的线性地址空间的末端 128K，是为参数表保留的，目前这个 p 就指向了参数表的开始处（偏移 4 字节）。

接下来两个 copy_strings 就是往这个参数表里面存放信息，不过具体存放的只是字符串常量值的信息，随后他们将被引用，有点像 Java 里 class 文件的字符串常量池思想。

// exec.c
int do_execve(...) 
    ...
    // p = 0x1FFF5 = 128K - 4 - 7
    p = copy_strings(envc,envp,page,p,0);
    // p = 0x1FFED = 128K - 4 - 7 - 8
    p = copy_strings(argc,argv,page,p,0);
    ...

具体说来，envp 表示字符串参数 “HOME=/”，argv 表示字符串参数 “/bin/sh”，两个 copy 就表示把这个字符串参数往参数表里存，相应地指针 p 也往下移动（共移动了 7 + 8 = 15 个字节），和压栈的效果是一样的。

当然，这个只是示意图，实际上这些字符串都是紧挨着的，我们通过 debug 查看参数表位置处的内存便可以看到真正存放的方式。

可以看到，两个字符串乖乖地被安排在了参数表内存处，且参数与参数之间用 00 也就是 NULL 来分隔。

接下来是更新局部描述符。

#define PAGE_SIZE 4096
#define MAX_ARG_PAGES 32

// exec.c
int do_execve(...) 
    ...
    // p = 0x3FFFFED = 64M - 4 - 7 - 8
    p += change_ldt(ex.a_text,page)-MAX_ARG_PAGES*PAGE_SIZE;
    ...

很简单，就是根据 ex.a_text 修改局部描述符中的代码段限长 code_limit，其他没动。

ex 结构里的 a_text 是生成 /bin/sh 这个 a.out 格式的文件时，写在头部的值，用来表示代码段的长度。至于具体是怎么生成的，我们无需关心。

ex结构保存了linux 0.11下a.out文件格式中每个可执行文件头信息，其中就包含当前可执行文件代码占据的大小，即为上面提到的a_text.

由于这个函数返回值是数据段限长，也就是 64M，所以最终的 p 值被调整为了以每个进程的线性地址空间视角下的地址偏移，大家可以仔细想想怎么算的。

接下来就是真正构造参数表的环节了。

#define PAGE_SIZE 4096
#define MAX_ARG_PAGES 32

// exec.c
int do_execve(...) 
    ...
    // p = 0x3FFFFD0
    p = (unsigned long) create_tables((char *)p,argc,envc);
    ...

刚刚仅仅是往参数表里面丢入了需要的字符串常量值信息，现在就需要真正把参数表构建起来。

我们展开 create_tables。

/*
 * create_tables() parses the env- and arg-strings in new user
 * memory and creates the pointer tables from them, and puts their
 * addresses on the "stack", returning the new stack pointer value.
 */
static unsigned long * create_tables(char * p,int argc,int envc) 
    unsigned long *argv,*envp;
    unsigned long * sp;

    sp = (unsigned long *) (0xfffffffc & (unsigned long) p);
    sp -= envc+1;
    envp = sp;
    sp -= argc+1;
    argv = sp;
    put_fs_long((unsigned long)envp,--sp);
    put_fs_long((unsigned long)argv,--sp);
    put_fs_long((unsigned long)argc,--sp);
    while (argc-->0) 
        put_fs_long((unsigned long) p,argv++);
        while (get_fs_byte(p++)) /* nothing */ ;
    
    put_fs_long(0,argv);
    while (envc-->0) 
        put_fs_long((unsigned long) p,envp++);
        while (get_fs_byte(p++)) /* nothing */ ;
    
    put_fs_long(0,envp);
    return sp;

可能稍稍有点烧脑，不过如果你一行一行仔细分析，不难分析出就是把参数表空间变成了如下样子。

最后，将 sp 返回给 p，这个 p 将作为一个新的栈顶指针，给即将要完成替换的 /bin/sh 程序，也就是下面的代码。

// exec.c
int do_execve(...) 
    ...
    // 设置栈指针
    eip[3] = p;

为什么这样操作就可以达到更换栈顶指针的作用呢？那我们结合着更换代码指针 PC 来进行讲解。

---

设置 eip 和 esp，完成摇身一变

下面这两行就是 execve 完成摇身一变的关键，解释了它为什么能做到变成一个新程序开始执行的关键密码。

// exec.c
int do_execve(unsigned long * eip, ...) 
    ...
    eip[0] = ex.a_entry;
    eip[3] = p; 
    ...

什么叫一个新程序开始执行呢？

其实本质上就是，代码指针 eip 和栈指针 esp 指向了一个新的地方。

代码指针 eip 决定了 CPU 将执行哪一段指令，栈指针 esp 决定了 CPU 压栈操作的位置，以及读取栈空间数据的位置，在高级语言视角下就是局部变量以及函数调用链的栈帧。

所以这两行代码，第一行重新设置了代码指针 eip 的值，指向 /bin/sh 这个 a.out 格式文件的头结构 exec 中的 a_entry 字段，表示该程序的入口地址。

第二行重新设置了栈指针 esp 的值，指向了我们经过一路计算得到的 p，也就是图中 sp 的值。将这个值作为新的栈顶十分合理。

eip 和 esp 都设置好了，那么程序摇身一变的工作，自然就结束了，非常简单。

至于为什么往 eip 的 0 和 3 索引位置处写入数据，就可以达到替换 eip 和 esp 的目的，那我们就得看看这个 eip 变量是怎么来的了。

此时还是处于内核态，如果程序要运行，势必需要通过中断返回指令，回到用户态运行，而中断返回硬件会自动弹出esp指向的内核栈相关数据,赋值给对应的寄存器，就包括上面提到的eip和esp。

计算机的世界没有魔法

还记得 execve 的调用链么？

static char * argv_rc[] =  "/bin/sh", NULL ;
static char * envp_rc[] =  "HOME=/", NULL ;

// 调用方
execve("/bin/sh",argv_rc,envp_rc);

// 宏定义
_syscall3(int,execve,const char *,file,char **,argv,char **,envp)

// 通过系统调用进入到这里
EIP = 0x1C
_sys_execve:
    lea EIP(%esp),%eax
    pushl %eax
    call _do_execve
    addl $4,%esp
    ret

// exec.c
int do_execve(unsigned long * eip, ...) 
    ...
    eip[0] = ex.a_entry;
    eip[3] = p; 
    ...

千万别忘了，我们这个 do_execve 函数，是通过一开始的 execve 函数触发了系统调用来到的这里。

系统调用是一种中断，前面说过，中断时 CPU 会给栈空间里压入一定的信息，这部分信息是死的，查手册可以查得到。

然后，进入中断以后，通过系统调用查表进入到 _sys_execve 这里。

EIP = 0x1C
_sys_execve:
    lea EIP(%esp),%eax
    pushl %eax
    call _do_execve
    addl $4,%esp
    ret

看到没？在真正调用 do_execve 函数时，_sys_execve 这段代码偷偷地插入了一个小步骤，就是把当前栈顶指针 esp 偏移到 EIP 处的地址值给当做第一个参数 unsigned long * eip 传入进来了。

而偏移 EIP 处的位置，恰好就是中断时压入的 EIP 的值的位置，表示中断发生前的指令寄存器的值。

所以 eip[0] 就表示栈空间里的 EIP 位置，eip[3] 就表示栈空间里的 ESP 位置。

此时eip[0]和eip[3]指向的是当前进程对应内核栈中已经压入的用户态EIP和ESP地址

由于我们现在处于中断，所以中断返回后，也就是 do_execve 这个函数 return 之后，就会寻找中断返回前的这几个值（包括 eip 和 esp）进行恢复。

这里有疑惑的同学，看下我之前写的 认认真真的聊聊中断 和 认认真真的聊聊"软"中断 这两篇文章，我认为把中断的原理彻底讲清楚了，不过其实就是读 CPU 手册罢了。

所以如果我们把这个栈空间里的 eip 和 esp 进行替换，换成执行 /bin/sh 所需要的 eip 和 esp，那么中断返回的恢复工作，就犹如跳转到一个新程序那里一样，其实是我们欺骗了 CPU，达到了 execve 这个函数的魔法效果。

所以，计算机的世界里根本没有魔法，就是通过这一点点细节而完成的，只是大部分人都不愿意花时间去细究这些细节罢了。

---

累了吧，休息会

本章讲解了我认为 Linux 0.11 里面最难理解的 execve 函数的核心逻辑，但其实整个顺下来你会发现，它所完成的事情也是由一个个非常简单的事情拼凑起来的。

无非就是把参数表在一个空间里折腾来折腾去给构造好，然后把代码应该从哪里执行的 eip 和新的栈空间应该设置在哪里的 esp 给弄好，就完成了使命。

至于 /bin/sh 文件是怎么构造出来的，那就是 gcc 编译和链接那些事了，而且 Linux 0.11 所用的可执行文件格式 a.out，已经被现在的 ELF 格式所取代，那就更不在我们要研究的范畴，本系列还是要划分好边界问题的，不然就无休止了。

OK，至此，execve 函数就彻底结束了。

void init(void) 
    ...
    if (!(pid=fork())) 
        close(0);
        open("/etc/rc",O_RDONLY,0);
        execve("/bin/sh",argv_rc,envp_rc);
        _exit(2);
    
    ...

他的返回意味着接下来将执行 /bin/sh 这个可执行文件里的代码。

不过有两个问题：

第一，/bin/sh 是躺在磁盘里的可执行文件，并不是 Linux 内核里的代码，所以其实那里面是什么，我们在 Linux 0.11 源码里是找不到的。也就是说，如果磁盘里并没有 /bin/sh 这个文件，Linux 0.11 是启动不起来的，在 open 的时候就会报错宕机了。

第二，我们只将 /bin/sh 文件的头部加载到了内存，其他部分并没有任何代码完成加载这个操作，那接下来跳转到一个并没有加载 /bin/sh 代码的内存时，会发生什么呢？

带着这两个疑问，期待后续的章节吧！

欲知后事如何，且听下回分解。

---

转载

本文转载至闪客图解操作系统系列文章