shell执行命令时参数传递过程

2024-10-31 18:10:36 #Linux #Bash #Execve

考虑以下代码 main.c ：

#include <stdio.h>
#include <stdlib.h>

int main(int argc, char *argv[], char *envp[])
{
    int i;
    argc += 0x88;
    printf("I am running here 0x%lx \n", argv);
    for (i = 0; i < argc; i ++) {
        printf("arg [%d]: %s \n", i, argv[i]);
    }
    for (char **env = envp; *env != 0; env++) {
        printf("env: %s \n", *env);
    }
    return 0;    
}

编译之后，运行:

1 2	gcc main.c -o main VAR=VALUE ./main arg1 arg2

结果输出为:

/ # VAR=VALUE ./main arg1 arg2
I am running here 0x7ffda5290e68 
arg [0]: ./main 
arg [1]: arg1 
arg [2]: arg2 
env: SHLVL=2 
env: HOME=/ 
env: VAR=VALUE 
env: TERM=linux 
env: HOST=x86_64 
env: PWD=/

问题：包括环境变量在内的参数是如何最终传递到main函数里的？

大体上，参数传递分为三部分：

shell传递给内核的sys_execve系统调用
sys_execve系统调用放入新进程的栈中
ELF的入口函数逐步传递到main函数中

本文的测试环境为：Linux longcc 5.17.7-200.fc35.x86_64 #1 SMP PREEMPT Thu May 12 14:56:48 UTC 2022 x86_64 x86_64 x86_64 GNU/Linux

shell传递给内核的sys_execve系统调用

以bash代码为例，这部分的调用过程为
-> main
-> reader_loop
-> execute_command
-> …
-> execve

execve的原型为: int execve(const char *pathname, char *const argv[], char *const envp[]);

shell构造参数的过程，这里就不记录了。

sys_execve系统调用放入新进程的栈中

这部分比较复杂，与Linux的ELF加载过程有关，本文的例子调用过程为：
do_execve -> do_execveat_common -> bprm_execve -> exec_binprm -> search_binary_handler

当进入内核态的系统调用时，调用参数和环境变量的指针存储在内核页中，但对应的内容存储在用户态页中。

接着，通过copy_strings，所有的参数和环境变量被复制到bprm结构中，此时，所有的内容都存储在内核页中。

在后面的调用过程中，begin_new_exec将确保仅有一条线程，同时通过exec_mmap对内存地址空间进行替换，旧有的映射关系将被全部丢弃。

search_binary_handler需要按照文件格式，查找对应的加载函数，接下来的过程为：
load_elf_binary -> start_thread

start_thread会进入ELF设置entry point执行， start_point的函数原型为: start_thread(struct pt_regs *regs, unsigned long new_ip, unsigned long new_sp)

进程的栈构造过程看load_elf_binary实现就比较清晰，大致结构如下:

------------------------------------------------------------- 0x7fff6c845000
 0x7fff6c844ff8: 0x0000000000000000
        _  4fec: './stackdump\0'                      <------+
  env  /   4fe2: 'ENVVAR2=2\0'                               |    <----+
       \_  4fd8: 'ENVVAR1=1\0'                               |   <---+ |
       /   4fd4: 'two\0'                                     |       | |     <----+
 args |    4fd0: 'one\0'                                     |       | |    <---+ |
       \_  4fcb: 'zero\0'                                    |       | |   <--+ | |
           3020: random gap padded to 16B boundary           |       | |      | | |
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -|       | |      | | |
           3019: 'x86_64\0'                        <-+       |       | |      | | |
 auxv      3009: random data: ed99b6...2adcc7        | <-+   |       | |      | | |
 data      3000: zero padding to align stack         |   |   |       | |      | | |
. . . . . . . . . . . . . . . . . . . . . . . . . . .|. .|. .|       | |      | | |
           2ff0: AT_NULL(0)=0                        |   |   |       | |      | | |
           2fe0: AT_PLATFORM(15)=0x7fff6c843019    --+   |   |       | |      | | |
           2fd0: AT_EXECFN(31)=0x7fff6c844fec      ------|---+       | |      | | |
           2fc0: AT_RANDOM(25)=0x7fff6c843009      ------+           | |      | | |
  ELF      2fb0: AT_SECURE(23)=0                                     | |      | | |
auxiliary  2fa0: AT_EGID(14)=1000                                    | |      | | |
 vector:   2f90: AT_GID(13)=1000                                     | |      | | |
(id,val)   2f80: AT_EUID(12)=1000                                    | |      | | |
  pairs    2f70: AT_UID(11)=1000                                     | |      | | |
           2f60: AT_ENTRY(9)=0x4010c0                                | |      | | |
           2f50: AT_FLAGS(8)=0                                       | |      | | |
           2f40: AT_BASE(7)=0x7ff6c1122000                           | |      | | |
           2f30: AT_PHNUM(5)=9                                       | |      | | |
           2f20: AT_PHENT(4)=56                                      | |      | | |
           2f10: AT_PHDR(3)=0x400040                                 | |      | | |
           2f00: AT_CLKTCK(17)=100                                   | |      | | |
           2ef0: AT_PAGESZ(6)=4096                                   | |      | | |
           2ee0: AT_HWCAP(16)=0xbfebfbff                             | |      | | |
           2ed0: AT_SYSINFO_EHDR(33)=0x7fff6c86b000                  | |      | | |
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .        | |      | | |
           2ec8: environ[2]=(nil)                                    | |      | | |
           2ec0: environ[1]=0x7fff6c844fe2         ------------------|-+      | | |
           2eb8: environ[0]=0x7fff6c844fd8         ------------------+        | | |
           2eb0: argv[3]=(nil)                                                | | |
           2ea8: argv[2]=0x7fff6c844fd4            ---------------------------|-|-+
           2ea0: argv[1]=0x7fff6c844fd0            ---------------------------|-+
           2e98: argv[0]=0x7fff6c844fcb            ---------------------------+
 0x7fff6c842e90: argc=3

事实上，当新进程从entry point开始执行时，此时的栈称为Initial process Stack。Initial process Stack的内存分布在此处进行了规定。

ELF的入口函数逐步传递到main函数中

这部分转递过程都是通过寄存器完成的，看汇编就很清晰了。
如果ELF是动态链接的，大致过程为entry point of ld-linux -> _start(entry point of libc) -> __libc_start_main -> main
如果是静态链接的，则没有第一步interpreter的处理。

其中_start的参数，参考内核的start_thread

__libc_start_main的函数原型为: LIBC_START_MAIN (int (*main) (int, char **, char ** MAIN_AUXVEC_DECL), int argc, char **argv)

有意思的一个地方，main可以有不同的参数个数，生成的汇编也是不一样的。

拓展结论

如果通过某种手段劫持ELF的entry point，修改参数(env + arg)需要以下过程:

重新设置stack结构，保留原内容的同时，塞入新参数
修改进程的寄存器，确保entry point函数读取到的是新的SP
修改mm_struct里的一堆参数，包括arg_start等等

大体上，就是重新实现了一遍create_aout_tables，这个思路与内核的实现高度耦合。

参考

2024-10-31 18:10:36 #Linux #Bash #Execve