# ELF 文件分类
Linux中，ELF文件全称为：Executable and Linkable Format，主要有三种形式，分别是：
可执行文件
动态库文件（共享文件 .so）
目标文件（可重定位文件 .o）
写个脚本测试一下：
准备两个 C 程序：a.c 和 b.c，内容如下：
// a.c
#include
void hello(void);
int main(void) {
hello();
return 0;
}
// b.c
#include
void hello(void) {
printf("hello a, b!\n");
}
接下来将b.c编译成动态链接库：
gcc -shared -o libb.so b.c -fPIC
将a.c编译成可执行文件：
gcc a.c ./libb.so
得到 4 个文件：
a.c a.out b.c libb.so
执行 ./a.out，可以输出：hello a, b!
为了测试，可以执行gcc -c a.c -o a.o，多编一个a.o，虽然用不到，权当对照。
此时可以用file命令查看文件信息：
file a.out
# 输出：a.out: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked...
file a.o
# 输出：a.o: ELF 64-bit LSB relocatable, x86-64, version 1 (SYSV), not stripped
file libb.so
# 输出：libb.so: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked...
可以看到，以上三个文件分属于不同的 ELF 种类。
# ELF 文件格式
ELF 文件的结构分为两个重要的部分：ELF头部分和ELF节表部分，其中节表部分被分成两种类型：节和程序段。ELF文件通过一个节表和程序头表指向这两个部分。具体结构如图：
即，同样的数据区域，既可以被视为节（sections），也可以被视为程序段（segments），其在不同的ELF文件中有所区分：
可执行文件：加载器则将把elf文件看作是程序头表描述的段的集合，一个段可能包含多个节，节头部表可选；
可重定位文件（.o）：一般编译器和链接器将把elf文件看作是节头表描述的节的集合，程序头表可选；
动态库文件（.so）：一般两者都有，因为链接器在链接的时候需要节头部表来查看目标文件各个 section 的信息然后对各个目标文件进行链接；而加载器在加载可执行程序的时候需要程序头表 ,它需要根据这个表把相应的段加载到进程自己的的虚拟内存（虚拟地址空间）中。
可以通过readelf工具查看 ELF 文件的内容：
# 查看 ELF 文件头
readelf -h [elf_file]
# 查看 ELF 文件 sections
readelf -S [elf_file]
# 查看 ELF 文件 segments
readelf -l [elf_file]
这里仅做抛砖引玉，具体的 ELF 文件各个字段的解释，以及动态链接 ELF 文件如何寻址填充，生成可执行文件，可以移步这篇文章：https://cloud.tencent.com/developer/article/2058294
# ELF 文件的执行流程
当执行./a.out命令时，首先开始工作的，是Linux集成的Bash程序。Bash 进程会做两件事情：
调用 fork() 系统调用，创建出一个新的进程，用来执行a.out任务；
调用 execve() 系统调用，执行这个 ELF 可执行文件a.out。
execve() 系统调用在内核源码fs/exec.c文件中被定义（kernel 版本 4.19）：
SYSCALL_DEFINE3(execve,
const char __user *, filename, // ELF 文件名
const char __user *const __user *, argv, // ELF 文件执行参数
const char __user *const __user *, envp) // 环境参数
{
return do_execve(getname(filename), argv, envp);
}
execve() 系统调用接收三个参数：文件名、执行参数和环境参数，其调用链为：
// execve 系统调用：fs/exec.c
SYSCALL_DEFINE3(execve, ...)
|-> do_execve()
|-> do_execveat_common()
|-> __do_execve_file() // (A)
|-> prepare_binprm(bprm)
|-> kernel_read(bprm->file, bprm->buf, BINPRM_BUF_SIZE, &pos)
|-> exec_binprm(bprm) // (B)
|-> search_binary_handler(bprm)
|-> security_bprm_check(bprm) // (C) lsm hook (include/linux/lsm_hooks.h)
|-> list_for_each_entry(fmt, &formats, lh) {
fmt->load_binary(bprm) // (D) load_elf_binary
}
值得注意的：
在内核中，一个 ELF 可执行文件会被解析为一个brpm结构，结构体为linux_binprm，定义在include/linux/binfmts.h中，核心字段如下：
struct linux_binprm {
char buf[BINPRM_BUF_SIZE]; // 存储 ELF 文件头，大小 128 字节
struct mm_struct *mm;
unsigned long p; // mem top 指针
struct file * file; // ELF 可执行文件指针
int argc, envc; // argv、envp 参数数量
const char * filename; // ELF 可执行文件名
}
在步骤（A）中：留意两件事情
调用prepare_binprm(bprm)，后者执行kernel_read(bprm->file, bprm->buf, BINPRM_BUF_SIZE, &pos)，将 ELF 文件的前BINPRM_BUF_SIZE大小（128字节）的内容填充到bprm->buf中；
对传入的参数进行处理，即，为运行参数 argv和环境参数envp分配内存页面（函数copy_strings()）；
随后调用（B）。
步骤（B）会调用search_binary_handler(bprm)选择合适的可执行文件处理器后，最终会调用load_elf_binary()函数真正加载这个 ELF 文件（步骤（D））。
Linux 支持其他不同格式的可执行程序, elf就是其中常见的一种可执行文件格式。在这种方式下, Linux 能运行其他操作系统所编译的程序, 如 MS-DOS 程序, 活 BSD Unix 的 COFF 可执行格式。
这里选择的是 ELF 二进制文件处理器。
引自：https://zhuanlan.zhihu.com/p/287863861
不过在步骤（D）执行之前，会进行一个security_bprm_check(bprm)过程（步骤（C））。该过程是 LSM 框架预设的 hook 点，用于在真正加载 ELF 文件前执行自定义的 check 回调，来实现安全控制。
步骤（D）中调用的其实是fmt->load_binary(bprm)，此乃linux_binfmt在初始化时，其成员函数指针内核预设的值，具体如下：
// 在文件 fs/binfmts.h 中
static struct linux_binfmt elf_format = {
.module = THIS_MODULE,
.load_binary = load_elf_binary,
.load_shlib = load_elf_library,
.core_dump = elf_core_dump,
.min_coredump = ELF_EXEC_PAGESIZE,
};
// elf_binfmt 初始化注册
static int __init init_elf_binfmt(void)
{
register_binfmt(&elf_format);
return 0;
}
// initcall
core_initcall(init_elf_binfmt);
# ELF文件的加载
在函数load_elf_binary()中，完成ELF文件的加载过程。
1）获取 ELF 头进行检查
/* Get the exec-header */
loc->elf_ex = *((struct elfhdr *)bprm->buf);
/* First of all, some simple consistency checks */
if (memcmp(loc->elf_ex.e_ident, ELFMAG, SELFMAG) != 0)
goto out;
if (loc->elf_ex.e_type != ET_EXEC && loc->elf_ex.e_type != ET_DYN)
goto out;
if (!elf_check_arch(&loc->elf_ex))
goto out;
if (elf_check_fdpic(&loc->elf_ex))
goto out;
这一步骤，首先从 bprm->buf中读取 ELF 头（prepare_binprm(bprm)），并判断文件前SELFMAG个字节是否为ELFMAG；
注：include/uapi/linux/elf.h
#define ELFMAG "\177ELF"
#define SEELFMAG 4
随后判断其文件类型是否为 “ET_EXEC” 和 “ET_DYN”，即，内核仅允许可执行ELF和动态链接ELF的加载。
2）加载程序头表
这一过程是通过load_elf_phdrs()函数完成的。该函数主要作用是，调用kernel_read()读取 ELF 文件的 程序头表：
// in load_elf_binary
elf_phdata = load_elf_phdrs(&loc->elf_ex, bprm->file);
if (!elf_phdata)
goto out;
// in load_elf_phdrs 保留关键逻辑
static struct elf_phdr *load_elf_phdrs(struct elfhdr *elf_ex,
struct file *elf_file)
{
/* Sanity check the number of program headers... */
if (elf_ex->e_phnum < 1 ||
elf_ex->e_phnum > 65536U / sizeof(struct elf_phdr))
goto out;
/* ...and their total size. */
size = sizeof(struct elf_phdr) * elf_ex->e_phnum;
elf_phdata = kmalloc(size, GFP_KERNEL);
/* Read in the program headers */
retval = kernel_read(elf_file, elf_phdata, size, &pos);
return elf_phdata;
}
在这个函数中，有几个细节值得注意：
ELF 文件至少有一个程序段，才能被成功加载；
所有段的大小不超过 65536U，即 64k；
最终 ELF 程序头表被保存在elf_phdata中。
3）处理动态链接的 ELF
如果当前加载的 ELF 文件是需要动态链接的，那么，程序最终会交给解释器执行，由解释器填充为链接库预留的程序段后，再真正交由程序执行。
因此，在这一步中，如果对 ELF 中定义的解释器段进行提取和解析，并加载到内存中。
需要动态链接的程序需要经由解释器来执行。例如上述的 a.out文件，其中动态链接了一个名为libb.so的共享库——具体而言，其代码中调用了libb.so的hello()函数。
这部分的核心代码逻辑为：
// in load_elf_binary
for (i = 0; i < loc->elf_ex.e_phnum; i++) {
if (elf_ppnt->p_type == PT_INTERP) {
// (A)
elf_interpreter = kmalloc(elf_ppnt->p_filesz, GFP_KERNEL);
pos = elf_ppnt->p_offset;
retval = kernel_read(bprm->file, elf_interpreter,
elf_ppnt->p_filesz, &pos);
// (B)
interpreter = open_exec(elf_interpreter);
// (C)
pos = 0;
retval = kernel_read(interpreter, &loc->interp_elf_ex,
sizeof(loc->interp_elf_ex), &pos);
// ...
}
}
这一步骤，遍历 ELF 文件的所有程序段，寻找PT_INTERP程序段，如果找到了，则主要做三件事：
（A）
elf_interpreter代表 解释器文件名，它是硬编码到 ELF 文件PT_INTERP程序段中的。举例来看：
执行readelf -l a.out查看上述的a.out ELF 可执行文件，结果如下：
可以看到，其中INTERP程序段中，从0x000238开始，大小为0x00001C的内容填充了一段名为/lib64/ld-linux-x86-64.so.2的字符串，代表了 Linux 系统的解释器。
/lib64/ld-linux-x86-64.so.2也是一个.so文件，但它是静态链接的，其本身不依赖任何其他的共享对象也不能使用全局和静态变量。这是合理的，试想，如果解释器都是动态链接的话，那么由谁来完成它的动态链接呢？
这里的解释器在32为系统上的路径名为：/lib/ld-linux.so.2
因此，步骤（A）仅是把PT_INTERP程序段的内容读取出来，存放到elf_interpreter变量中。
（B）找到了elf_interpreter后，尝试打开它。
（C）读取解释器（/lib64/ld-linux-x86-64.so.2）的 ELF 文件头。
4）处理可执行栈
该步骤的逻辑：
// in load_elf_binary
for (i = 0; i < loc->elf_ex.e_phnum; i++, elf_ppnt++)
switch (elf_ppnt->p_type) {
case PT_GNU_STACK:
// ...
break;
// ...
}
}
gcc编译选项中，开始/关闭可执行栈的选项是 -z execstack/noexecstack，默认情况下gcc是关闭可执行栈的。在加载 ELF 文件时，会遍历所有的segment，找到PT_GNU_STACK，即栈段，检查flags。
具体可参考：https://mudongliang.github.io/2015/10/23/elf.html
5）解释器的检查工作
这一步骤主要检查刚刚打开的解释器的合法性，主要包括以下几个方面：
是否是一个 ELF 解释器？
架构信息是否合法？
加载解释器程序头表
执行前的最后校验（arch_check_elf()，此函数节点是执行前的最后确认，在此之前，exec系统调用仍然可以发挥一个 error code）
6）重建用户空间映射
这一步骤中，ELF 文件即将蜕变为一个真正的进程，首先为其重建用户空间：
// in load_elf_binary
/* Flush all traces of the currently running executable */
retval = flush_old_exec(bprm);
// ...
setup_new_exec(bprm);
install_exec_creds(bprm);
/* Do this so that we can load the interpreter, if need be. We will
change some of these later */
retval = setup_arg_pages(bprm, randomize_stack_top(STACK_TOP), executable_stack);
current->mm->start_stack = bprm->p;
在这一过程中，首先调用flush_old_exec释放当前进程的所有用户空间页面映射；紧接着，进行必要的setup和install过程；最后，调用setup_arg_pages()，将前文（copy_strings()）为argv和envp分配的页面重新映射回用户空间。
7）载入 LOAD 程序段
此为关键步骤，仍然是遍历所有的程序段，寻找PT_LOAD段，并将其载入到某个地址上（实际上是建立映射关系）。
// in load_elf_binary
for(i = 0, elf_ppnt = elf_phdata; i < loc->elf_ex.e_phnum; i++, elf_ppnt++) {
if (elf_ppnt->p_type != PT_LOAD)
continue;
if (elf_ppnt->p_flags & PF_R) elf_prot |= PROT_READ;
if (elf_ppnt->p_flags & PF_W) elf_prot |= PROT_WRITE;
if (elf_ppnt->p_flags & PF_X) elf_prot |= PROT_EXEC;
// ...
vaddr = elf_ppnt->p_vaddr;
// ...
error = elf_map(bprm->file, load_bias + vaddr, elf_ppnt,
elf_prot, elf_flags, total_size);
}
这一过程中，首先定位PT_LOAD程序段，然后，保存 R/W/X 权限信息，最后进行地址映射。
8）定位程序的入口
进行到此步骤时，当前 ELF 可执行程序 和解释器均已加载完成，并且各类准备工作也已经执行完毕，接下来要做的，就是找到程序的入口。
// in load_elf_binary
if (elf_interpreter) {
unsigned long interp_map_addr = 0;
elf_entry = load_elf_interp(&loc->interp_elf_ex,
interpreter,
&interp_map_addr,
load_bias, interp_elf_phdata);
} else {
elf_entry = loc->elf_ex.e_entry;
}
很简单，若当前 ELF 依赖解释器，则入口地址设置为解释器的入口地址；否则设置为 ELF 本身的入口地址。
9）准备执行
进程栈的设置（参数、环境变量...）
current->mm 的设置
...
调用start_thread(regs, elf_entry, bprm->p)开始执行
# ELF 文件的执行
load_elf_binary()函数最终调用start_thread(regs, elf_entry, bprm->p)启动执行流程。
对于x86架构而言，start_thread()定义在arch/x86/k ernel/process_64.c文件中：
void
start_thread(struct pt_regs *regs, unsigned long new_ip, unsigned long new_sp)
{
start_thread_common(regs, new_ip, new_sp,
__USER_CS, __USER_DS, 0);
}
EXPORT_SYMBOL_GPL(start_thread);
其中，new_ip 就是 ELF 文件的入口地址：elf_entry，后续指令将跳转此处开始执行。