Mar*_*iro 10 memory elf x86 linux-kernel 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]
Run Code Online (Sandbox Code Playgroud)
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
Run Code Online (Sandbox Code Playgroud)
我在这里使用了不同的常量值0x7fe000来看看会发生什么,对于这个值,我是否得到段错误是不确定的。根据 GDB 的说法,subq指令本身会扩大 mmap 的大小,这对我来说很神秘(linux 怎么知道我的寄存器中有什么?),但是这个程序通常会出于某种原因在退出时使 GDB 崩溃。不可能是 ASLR 导致不确定性,因为我没有使用 GOT 或任何 PLT 部分;可执行文件每次总是加载在虚拟内存中的相同位置。那么这是 PID 或物理内存泄漏的某种随机性吗?总而言之,我很困惑到底有多少堆栈实际上可以合法地用于随机访问,以及在更改 RSP 或写入“刚刚超出范围”的区域时需要多少堆栈
我不相信这个问题真的与ELF有关。据我所知,ELF 定义了一种将程序映像“扁平打包”到文件中,然后重新组装它以备第一次执行的方法。如果操作系统行为没有提升到 POSIX,那么堆栈是什么以及它是如何实现的定义介于 CPU 特定和操作系统特定之间。 尽管毫无疑问,ELF 规范对堆栈中的需求提出了一些要求。
从你的问题:
我知道堆栈正下方的页面是一个“保护页面”,如果我写入它,它会自动变得可写并“沿着堆栈向下增长”(大概是这样简单的堆栈处理“正常工作”),但是如果我分配一个巨大的堆栈框架然后我可能会超过保护页面和段错误,所以我想确定在进程开始时已经正确分配了多少空间。
我正在努力为此找到权威参考。但是我发现了足够多的非权威参考资料表明这是不正确的。
从我读过的内容来看,保护页用于捕获最大堆栈分配之外的访问,而不是用于“正常”堆栈增长。实际的内存分配(将页面映射到内存地址)是按需完成的。即:当访问内存中栈基和栈基之间的未映射地址 - 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)。
我不知道 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
| 归档时间: |
|
| 查看次数: |
2145 次 |
| 最近记录: |