主页 / unix / 问题 / 521960
Accepted
Mario Carneiro
Asked: 2019-05-31 04:35:53 +0800 CST

ELF 加载器如何确定初始堆栈大小？

  • 772

我正在研究 ELF 规范（http://www.skyfree.org/linux/references/ELF_Format.pdf），关于程序加载过程我不清楚的一点是堆栈是如何初始化的，以及初始页面大小是。这是测试（在 Ubuntu x86-64 上）：

$ cat test.s
.text
  .global _start
_start:
  mov $0x3c,%eax
  mov $0,%edi
  syscall
$ as test.s -o test.o && ld test.o
$ gdb a.out -q
Reading symbols from a.out...(no debugging symbols found)...done.
(gdb) b _start
Breakpoint 1 at 0x400078
(gdb) run
Starting program: ~/a.out 

Breakpoint 1, 0x0000000000400078 in _start ()
(gdb) print $sp
$1 = (void *) 0x7fffffffdf00
(gdb) info proc map
process 20062
Mapped address spaces:

          Start Addr           End Addr       Size     Offset objfile
            0x400000           0x401000     0x1000        0x0 ~/a.out
      0x7ffff7ffa000     0x7ffff7ffd000     0x3000        0x0 [vvar]
      0x7ffff7ffd000     0x7ffff7fff000     0x2000        0x0 [vdso]
      0x7ffffffde000     0x7ffffffff000    0x21000        0x0 [stack]
  0xffffffffff600000 0xffffffffff601000     0x1000        0x0 [vsyscall]

ELF 规范对这个堆栈页面如何或为什么首先存在几乎没有说明，但我可以找到说明堆栈应该初始化为 SP 指向 argc，argv、envp 和辅助向量就在上面我已经证实了这一点。但是在 SP 之下还有多少可用空间呢？在我的系统上，0x1FF00在 SP 下方映射了字节，但大概是从堆栈顶部的 处倒数，并且在完整映射中0x7ffffffff000有字节。0x21000什么影响这个数字？

我知道堆栈下方的页面是一个“保护页面”，如果我写入它，它会自动变为可写并“在堆栈中向下增长”（大概是这样天真的堆栈处理“正常工作”），但是如果我分配一个巨大的堆栈帧，那么我可能会超出保护页面和段错误，所以我想确定在进程启动时已经正确分配了多少空间。

编辑：更多数据让我更加不确定发生了什么。测试如下：

.text
  .global _start
_start:
  subq $0x7fe000,%rsp
  movq $1,(%rsp)
  mov $0x3c,%eax
  mov $0,%edi
  syscall

我在0x7fe000这里使用了不同的常量值来看看会发生什么，对于这个值，我是否得到段错误是不确定的。根据 GDB 的说法，这subq条指令本身会扩大 mmap 的大小，这对我来说很神秘（linux 怎么知道我的寄存器中有什么？），但是这个程序通常会由于某种原因在退出时使 GDB 崩溃。不可能是 ASLR 导致不确定性，因为我没有使用 GOT 或任何 PLT 部分；可执行文件每次总是加载到虚拟内存中的相同位置。那么这是 PID 或物理内存的一些随机性吗？总而言之，我很困惑到底有多少堆栈实际上合法可用于随机访问，以及更改 RSP 或写入“刚刚超出范围”的区域需要多少

linux-kernel memory

2 个回答

  1. Best Answer

    我不相信这个问题真的与 ELF 有关。据我所知，ELF 定义了一种将程序映像“扁平打包”到文件中，然后重新组装它以供首次执行的方法。如果操作系统行为尚未提升到 POSIX，那么堆栈是什么以及如何实现的定义位于特定于 CPU 和特定于操作系统之间。 尽管毫无疑问，ELF 规范对堆栈所需的内容提出了一些要求。

    最小堆栈分配

    从你的问题：

    我知道堆栈下方的页面是一个“保护页面”，如果我写入它，它会自动变为可写并“在堆栈中向下增长”（大概是这样天真的堆栈处理“正常工作”），但是如果我分配一个巨大的堆栈帧，那么我可能会超出保护页面和段错误，所以我想确定在进程启动时已经正确分配了多少空间。

    我正在努力为此寻找权威参考。但我发现足够多的非权威参考资料表明这是不正确的。

    根据我的阅读，保护页面用于捕获最大堆栈分配之外的访问，而不是用于“正常”堆栈增长。实际的内存分配（将页面映射到内存地址）是按需完成的。即：当访问内存中未映射的地址时，在stack-base和stack-base - max-stack-size + 1之间，CPU可能会触发异常，但内核将通过映射页面来处理异常内存，而不是级联分段错误。

    因此访问最大分配内的堆栈不应导致分段错误。正如你所发现的

    最大堆栈分配

    调查文档应该遵循关于线程创建和图像加载的 Linux 文档行（fork(2)、clone(2)、execve(2)）。 execve 的文档提到了一些有趣的事情：

    参数大小和环境的限制

    ……剪……

    在内核 2.6.23 及更高版本上，大多数体系结构都支持从软RLIMIT_STACK资源限制派生的大小限制（请参阅getrlimit(2)）

    ……剪……

    这证实了限制需要体系结构来支持它，并且还引用了它的限制位置（getrlimit(2)）。

    RLIMIT_STACK

    这是进程堆栈的最大大小，以字节为单位。达到此限制后，将生成 SIGSEGV 信号。要处理此信号，进程必须使用备用信号堆栈 (sigaltstack(2))。

    从 Linux 2.6.23 开始，这个限制也决定了进程的命令行参数和环境变量使用的空间量；有关详细信息，请参阅 execve(2)。

    通过更改 RSP 寄存器来增加堆栈

    我不知道 x86 汇编程序。 但是我会提请您注意在更改 SS 寄存器时可以由 x86 CPU 触发的“堆栈故障异常”。 如果我错了，请纠正我，但我相信 x86-64 SS:SP 刚刚变成“RSP”。因此，如果我理解正确，可以通过递减的 RSP ( subq $0x7fe000,%rsp) 触发堆栈故障异常。

    请参阅此处的第 222 页：https ://xem.github.io/minix86/manual/intel-x86-and-64-manual-vol3/o_fe12b1e2a880e0ce.html

    • 6

  2. 每个进程内存区域（例如代码、静态数据、堆、堆栈等）都有边界，任何区域之外的内存访问，或对只读区域的写访问都会产生 CPU 异常。内核维护这些内存区域。区域外的访问以分段错误信号的形式传播到用户空间。

    并非所有异常都是通过访问区域外的内存产生的。区域内访问也可能产生异常。例如，如果页面没有映射到物理内存，则页面错误处理程序对正在运行的进程透明地处理它。

    进程主堆栈区域最初只有少量映射到它的页框，但当更多数据通过堆栈指针推送到它时会自动增长。异常处理程序检查访问是否仍在为堆栈保留的区域内，如果是，则分配新的页框。从用户级代码的角度来看，这是自动发生的。

    保护页被放置在堆栈区域的末尾之后，以检测堆栈区域的溢出。最近（2017 年）有些人意识到单个保护页是不够的，因为程序可能会被欺骗以大量减少堆栈指针，这可能会使堆栈指针指向其他允许写入的区域。这个问题的“解决方案”是用 1 MB 保护区域替换 4 kB 保护页面。请参阅这篇LWN 文章。

    应该注意的是，这个漏洞并不是完全可以利用的，它要求，例如，用户可以通过调用来控制程序分配的内存量alloca。健壮的程序应该检查传递给 的参数alloca，特别是如果它是从用户输入派生的。

    • 4

相关问题