linux - `[stack]` 、 `[vdso]` 和 `[vsyscall]` mmaps 从哪里来？

Question

考虑以下针对 Linux x86_64 的程序:

inf.s:

    .global _start
    .text
_start:
    jmp _start

这基本上是一个无限循环。

如果我链接并剥离它，我会得到一个 ELF 可执行文件:

$ gcc -nostdlib inf.s

$ ./a.out &

[1] 15862

$ cat /proc/15862/maps

00400000-00401000 r-xp 00000000 fc:00 11404632           a.out
7fffacdb8000-7fffacdd9000 rwxp 00000000 00:00 0          [stack]
7fffacddd000-7fffacdde000 r-xp 00000000 00:00 0          [vdso]
ffffffffff600000-ffffffffff601000 r-xp 00000000 00:00 0  [vsyscall]

在 ELF 可执行文件中，第一个程序头 LOAD 包含占上述 mmaps (a.out) 中第一个条目的映射。 (即使我剥离了所有内容，但此 header 和代码也观察到相同的映射。)execve(2) 调用 fs/binfmt_elf.c 中的 ELF 处理程序，它读取程序 header 并在文件上调用 mmap。

我不明白的是其他三个来自哪里(stack、vdso、vsyscall)。它们在 ELF 文件中没有提及，因此 Linux 内核必须默认设置这三个“匿名”或“特殊”映射。

我的问题是 Linux 内核在内核代码中的什么位置(或如何)创建其他三个映射？它们是在整个执行过程中继承的吗？我似乎看不到它们是在 fs/exec.c 中创建的。

Answer 1

当内核将文件加载到内存中运行时，它们由内核自动创建。

[vdso] 和 [vsyscall] 的精确控制流程很难遵循，因为函数名称的定义和重新定义为宏，具体取决于是否内核是 32 位或 64 位，但一些相关例程包括:

• load_elf_binary 在 fs/binfmt_elf.c 中调用 arch_setup_additional_pages
• arch_setup_additional_pages 在 arch/x86/vdso/vma.c
• arch_setup_additional_pages 在 arch/x86/vdso/vdso32-setup.c

[stack] 映射不是 ELF 特定的，它是由 fs/exec.c 中的 __bprm_mm_init 创建的，它由 execve 调用格式特定加载器之前的代码。