在本文中，您将了解当一个进程调用execve()时，Linux内核内部发生了什么，内核如何准备栈，并且控制权如何传递给用户空间进程进行执行。

概述

1. 内核接收用户空间程序的SYS_execve()调用。
2. 内核将可执行文件（特定部分）读入特定的内存位置。
3. 内核准备栈、堆、信号等。
4. 内核将执行权传递给用户空间程序。

检查二进制文件

我们从一个简单的Linux C程序开始：

int main(int argc, char *argv[0]) {
        return 0;
}

使用gcc -static -o none none.c编译它，并找出一些细节：

$ readelf -h none
ELF Header:
  Magic:   7f 45 4c 46 02 01 01 03 00 00 00 00 00 00 00 00
  Class:                             ELF64
  Data:                              2's complement, little endian
  Version:                           1 (current)
  OS/ABI:                            UNIX - GNU
  ABI Version:                       0
  Type:                              EXEC (Executable file)
  Machine:                           Advanced Micro Devices X86-64
  Version:                           0x1
  Entry point address:               0x4014f0
  Start of program headers:          64 (bytes into file)
  Start of section headers:          760112 (bytes into file)
  Flags:                             0x0
  Size of this header:               64 (bytes)
  Size of program headers:           56 (bytes)
  Number of program headers:         10
  Size of section headers:           64 (bytes)
  Number of section headers:         30
  Section header string table index: 29

第一条指令从0x4014f0的“入口点”开始。这些指令是由编译器（gcc、go等）生成的。它们根据编译器的不同而有所不同。

让我们将二进制文件加载到gdb中，并对0x4014f0处的指令进行反汇编。这些指令执行一些清理工作，但最终会调用main()函数（或Go语言的等效函数）。

让我们在入口点（0x4014f0）设置一个断点，并使用两个命令行选项（firstarg和secondarg）运行该应用程序：

gdb ./none
pwndbg> disass 0x4014f0
pwndbg> br *0x4014f0
pwndbg> r firstarg secondarg
 ? 0x4014f0 <_start>       xor    ebp, ebp
   0x4014f2 <_start+2>     mov    r9, rdx
   0x4014f5 <_start+5>     pop    rsi
[...]
──────────────────────[ STACK ]──────────────────────
00:0000│ rsp 0x7ffca4229540 ?— 0x3
01:0008│     0x7ffca4229548 —? 0x7ffca422a4b3 ?— '/sec/root/none'
02:0010│     0x7ffca4229550 —? 0x7ffca422a4c2 ?— 'firstarg'
03:0018│     0x7ffca4229558 —? 0x7ffca422a4cb ?— 'secondarg'
04:0020│     0x7ffca4229560 ?— 0x0
05:0028│     0x7ffca4229568 —? 0x7ffca422a4d5 ?— 'BASH_ENV=/etc/shellrc'
[...]

（如果您使用的是没有pwngdb的gdb，则可能需要使用x/64a $rsp来列出堆栈的前64个条目。）

堆栈指针rsp位于0x7ffd4f48bd10。让我们使用grep -F '[stack]' /proc/$(pidof none)/maps找出堆栈的结束位置：

7ffd4f46c000-7ffd4f48d000 rw-p 00000000 00:00 0         [stack]

内核已将堆栈内存分配从0x7ffd4f46c000到0x7ffd4f48d000，总共132 KB。它将动态增长到8MB（ulimit -s kilobytes）。我们的程序（目前为止；参见rsp）只使用从rsp地址（0x7ffd4f48bd10）向下到堆栈的相同结束位置（0x7ffd4f48d000）的堆栈，共计4,848字节（echo $((0x7ffd4f48d000 - 0x7ffd4f48bd10)) == 4848）。

这是执行的“诞生”：内核将控制权交给了我们的程序。我们的程序即将执行它的第一条指令——迈出第一步（可以这么说）。

堆栈上现在包含了程序从内核获取的所有运行信息。它包含了参数列表、环境变量和许多其他有趣的信息。

让我们dump堆栈：

pwndbg> dump binary memory stack.dat $rsp 0x7ffd4f48d000

然后将其加载到hd <stack.dat或者xxd <stack.dat，并进行一次小小的预览...

 03 00 00 00 00 00 00 00  b3 a4 22 a4 fc 7f 00 00  |..........".....|
 c2 a4 22 a4 fc 7f 00 00  cb a4 22 a4 fc 7f 00 00  |..".......".....|
 00 00 00 00 00 00 00 00  d5 a4 22 a4 fc 7f 00 00  |..........".....|
 eb a4 22 a4 fc 7f 00 00  11 a5 22 a4 fc 7f 00 00  |..".......".....|
 25 a5 22 a4 fc 7f 00 00  30 a5 22 a4 fc 7f 00 00  |%.".....0.".....|
[...]
 b4 5c 18 e0 ed f9 fb 0d  30 78 38 36 5f 36 34 00  |.\......0x86_64.|
 00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
 00 00 00 2f 73 65 63 2f  72 6f 6f 74 2f 6e 6f 6e  |.../sec/root/non|
 65 00 66 69 72 73 74 61  72 67 00 73 65 63 6f 6e  |e.firstarg.secon|
 64 61 72 67 00 42 41 53  48 5f 45 4e 56 3d 2f 65  |darg.BASH_ENV=/e|
 74 63 2f 73 68 65 6c 6c  72 63 00 43 48 45 41 54  |tc/shellrc.CHEAT|
 5f 43 4f 4e 46 49 47 5f  50 41 54 48 3d 2f 65 74  |_CONFIG_PATH=/et|
[...]
 55 4d 4e 53 3d 31 31 38  00 2f 73 65 63 2f 72 6f  |UMNS=118./sec/ro|
 6f 74 2f 6e 6f 6e 65 00  00 00 00 00 00 00 00 00  |ot/none.........|

很多指针。很多字符串。很多未知的内容。

让我们跟踪从execve()到程序的入口点的调用。

execve()通过系统调用调用内核，然后调用do_execve()函数：

最终，这将进入do_execveat_common()函数。bprm结构被创建，并将关于程序的各种信息分配给它（参见binfmts.h）。

对于我们来说，程序的文件名、环境变量和选项（argv）从内核内存复制到进程的堆栈中。堆栈向较低的地址增长：堆栈上放置的第一项（bprm->filename）因此位于堆栈的最大地址（底部），在它的上方（较小的地址）是envp，然后是argv。

我们继续跟踪到bprm_execve()函数，在调用exec_binprm()之前完成一些检查。然后进入search_binary_handler()函数，内核检查二进制文件是否为ELF格式、是否为shebang（#!）或是否是通过binfmt-misc模块注册的其他类型。内核然后调用适当的函数来加载二进制文件。

在我们的情况下，它是一个ELF二进制文件，因此调用load_elf_binary()函数。内核创建内存，然后将二进制文件的节映射到内存中。它调用begin_new_exec()函数为新进程设置所有的凭据和权限。

然后，内核检查ELF二进制文件是否应该由解释器（ld.so）加载：

或者，对于像我们的静态二进制文件这样的情况，直接加载而无需解释器：

最后，调用create_elf_tables()函数。这是我们感兴趣的堆栈魔术发生的地方。

首先，函数arch_align_stack()向堆栈中添加随机数量的零（例如堆栈随机化），以使（某些）缓冲区溢出攻击的可靠性稍微降低。然后，它将堆栈对齐到16字节（例如，将堆栈指针设置为下一个较低的地址，该地址与16字节对齐，使用& ~0xf）。

然后，内核将"x86_64\0"放入堆栈中，然后在其上方添加16字节的随机数据（libc将其用作其伪随机数生成器的种子）：

然后，内核创建ELF辅助表：这是一个包含（id，value）对的集合，描述正在运行的程序以及它所运行的环境的有用信息，从内核传递到用户空间。

列表以零标识符和零值（例如16字节的0x00）结束。列表中大约有20个条目（320字节）。

表以ARCH_DLINFO（它展开为AT_SYSINFO_EHDR + AT_MINSIGSTKSZ）开始。

这些“标识符”在auxvec.h中定义：

在gdb中，我们程序的堆栈上的ELF辅助表如下所示（注意：上面的“标识符”值是十进制的，但gdb显示为十六进制）：

[... above is argc ...]
[... above is argvp ...]
[... above here is envp ...]
0x7ffca42296a8: 0x21    0x7ffca4351000    <-- AT_SYSINFO_EDHR
0x7ffca42296b8: 0x33    0xd30             <-- AT_MINSIGSTKSZ
0x7ffca42296c8: 0x10    0x178bfbff        <-- AT_HWCAP
0x7ffca42296d8: 0x6     0x1000            <-- AT_PAGESZ
0x7ffca42296e8: 0x11    0x64
0x7ffca42296f8: 0x3     0x400040
0x7ffca4229708: 0x4     0x38
0x7ffca4229718: 0x5     0xa
0x7ffca4229728: 0x7     0x0
0x7ffca4229738: 0x8     0x0
0x7ffca4229748: 0x9     0x4014f0         <-- Our entry point
0x7ffca4229758: 0xb     0x0
0x7ffca4229768: 0xc     0x0
0x7ffca4229778: 0xd     0x0
0x7ffca4229788: 0xe     0x0
0x7ffca4229798: 0x17    0x0
0x7ffca42297a8: 0x19    0x7ffca42297f9   <-- Ptr to Random
0x7ffca42297b8: 0x1a    0x2
0x7ffca42297c8: 0x1f    0x7ffca422afe9   <-- Ptr to filename
0x7ffca42297d8: 0xf     0x7ffca4229809   <-- Ptr to x86_64
0x7ffca42297e8: 0x0     0x0                  <-- NULL + NULL
[... ELF table stops here ...]
0x7ffca42297f8: 0xe8e8de3a49831f00      0xdfbf9ede0185cb4 <-- RND16
0x7ffca4229808: 0x34365f363878af        0x0  <-- "x86_64" + '\0'
[... below is empty space from stack randomization ...]
[... below are argv strings ...]
[... below are env strings ...]
[... last is the filename (/root/none) ...]

然后，内核分配堆栈内存来存储elf-aux表、argv和env指针以及argc值（+1），并将堆栈顶部对齐到16字节。（它尚未将elf-aux表复制到堆栈上。这将在稍后进行）：

...然后将argc、argv指针和env指针放入堆栈中：

...然后将elf-aux表（即上述的elf_info）复制到堆栈上（对齐后，在env指针的下方）。

(聪明的读者可能会注意到，'RND16'并不以对齐的地址开始 - 0x7ffca42297f9：这是因为在调用STACK_ROUND()函数将elf-info表和env/argv指针放入堆栈之前，RND16已经被放入了堆栈中。)

现在回到load_elf_binary()函数中，内核设置寄存器，清除一些内容，最后 (!) 调用START_THREAD()函数来启动程序。

事后想法：有人指出https://lwn.net/Articles/631631/。他们的ASCII艺术比我的好。它展示了在执行之前堆栈的布局（但是他们把它画反了；从顶部开始以最大地址，最底部是最小地址）：