☰

最小堆栈分配

tag-icon • tag-icon linux-kernel memory x86 elf stack
最小堆栈分配

我正在研究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 规范对于这个堆栈页如何或为何存在一开始几乎没有说明，但我可以找到一些参考资料，其中指出堆栈应该使用指向 argc 的 SP 进行初始化，其中 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 或写入“刚好超出范围”的合法内存区域时需要多少堆栈。

答案1

我不认为这个问题真的与 ELF 有关。据我所知，ELF定义了一种方法“扁平包装“将程序映像写入文件，然后重新组装以准备首次执行。如果操作系统行为尚未提升到 POSIX，那么堆栈的定义及其实现方式介于 CPU 特定和操作系统特定之间。 尽管毫无疑问，ELF 规范对其堆栈上的需求提出了一些要求。

最小堆栈分配

从你的问题来看：

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

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

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

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

最大堆栈分配

研究文档应该遵循有关线程创建和图像加载的 Linux 文档（叉子(2),克隆（2）,执行(2)）。 execve 的文档提到了一些有趣的事情：

参数大小和环境的限制

...剪断...

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

...剪断...

这证实了该限制需要架构支持它，并且还引用了它的限制（获取限制(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

答案2

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

并非所有异常都是通过访问区域之外的内存生成的。区域内访问也可能会生成异常。例如，如果页面未映射到物理内存，则页面错误处理程序会以对正在运行的进程透明的方式处理此问题。

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

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

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

相关内容