Pet*_*des 6 linux x86 assembly mmap linux-kernel
尝试测试时是否允许访问跨越x86中零边界的内存？在Linux的用户空间中，我编写了一个32位测试程序，该程序试图映射32位虚拟地址空间的低和高页。
之后echo 0 | sudo tee /proc/sys/vm/mmap_min_addr，我可以映射零页面，但是我不知道为什么不能映射-4096（即(void*)0xfffff000最高页面）。 为什么要mmap2((void*)-4096)退货-ENOMEM？
strace ./a.out
execve("./a.out", ["./a.out"], 0x7ffe08827c10 /* 65 vars */) = 0
strace: [ Process PID=1407 runs in 32 bit mode. ]
....
mmap2(0xfffff000, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = -1 ENOMEM (Cannot allocate memory)
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0
另外，什么支票在中拒绝它linux/mm/mmap.c，为什么要这样设计？这是确保创建指向一个过去的对象的指针不会回绕并中断指针比较的部分吗，因为ISO C和C ++允许创建指向过去的一个指针，但不能在外部对象。
我在64位内核（Arch Linux上为4.12.8-2-ARCH）下运行，因此32位用户空间具有整个可用的4GiB。（与64位内核或32位内核（其中2：2或3：1用户/内核拆分会使高页成为内核地址）上的64位代码不同。）
我没有尝试使用最小的静态可执行文件（没有CRT启动程序或libc，只有asm），因为我认为这不会有所作为。没有一个CRT启动系统调用看起来可疑。
在断点处停下来时，我检查了一下/proc/PID/maps。主页尚未使用。堆栈包括第二高的页面，但未映射首页。
00000000-00001000 rw-p 00000000 00:00 0 ### the mmap(0) result
08048000-08049000 r-xp 00000000 00:15 3120510 /home/peter/src/SO/a.out
08049000-0804a000 r--p 00000000 00:15 3120510 /home/peter/src/SO/a.out
0804a000-0804b000 rw-p 00001000 00:15 3120510 /home/peter/src/SO/a.out
f7d81000-f7f3a000 r-xp 00000000 00:15 1511498 /usr/lib32/libc-2.25.so
f7f3a000-f7f3c000 r--p 001b8000 00:15 1511498 /usr/lib32/libc-2.25.so
f7f3c000-f7f3d000 rw-p 001ba000 00:15 1511498 /usr/lib32/libc-2.25.so
f7f3d000-f7f40000 rw-p 00000000 00:00 0
f7f7c000-f7f7e000 rw-p 00000000 00:00 0
f7f7e000-f7f81000 r--p 00000000 00:00 0 [vvar]
f7f81000-f7f83000 r-xp 00000000 00:00 0 [vdso]
f7f83000-f7fa6000 r-xp 00000000 00:15 1511499 /usr/lib32/ld-2.25.so
f7fa6000-f7fa7000 r--p 00022000 00:15 1511499 /usr/lib32/ld-2.25.so
f7fa7000-f7fa8000 rw-p 00023000 00:15 1511499 /usr/lib32/ld-2.25.so
fffdd000-ffffe000 rw-p 00000000 00:00 0 [stack]
是否有没有出现的VMA区域maps仍然说服内核拒绝该地址？我查看了ENOMEMin 的出现linux/mm/mmapc.，但是要阅读很多代码，所以也许我错过了一些东西。保留一些高地址范围的东西，还是因为它在堆栈旁边？
以其他顺序进行系统调用无济于事（但是PAGE_ALIGN和类似的宏会被仔细地编写，以避免在屏蔽之前回绕，因此无论如何都不可能。）
完整源代码，使用编译gcc -O3 -fno-pie -no-pie -m32 address-wrap.c：
strace ./a.out
execve("./a.out", ["./a.out"], 0x7ffe08827c10 /* 65 vars */) = 0
strace: [ Process PID=1407 runs in 32 bit mode. ]
....
mmap2(0xfffff000, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = -1 ENOMEM (Cannot allocate memory)
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0
（我省去了尝试取消引用的部分，(int*)-2因为它在mmap失败时只会出现段错误。）
mmap函数最终调用do_mmap或do_brk_flags，它们执行满足内存分配请求的实际工作。这些函数依次调用get_unmapped_area。正是在该函数中进行检查，以确保不能分配超出TASK_SIZE定义的用户地址空间限制的内存。我引用代码：
* There are a few constraints that determine this:
*
* On Intel CPUs, if a SYSCALL instruction is at the highest canonical
* address, then that syscall will enter the kernel with a
* non-canonical return address, and SYSRET will explode dangerously.
* We avoid this particular problem by preventing anything executable
* from being mapped at the maximum canonical address.
*
* On AMD CPUs in the Ryzen family, there's a nasty bug in which the
* CPUs malfunction if they execute code from the highest canonical page.
* They'll speculate right off the end of the canonical space, and
* bad things happen. This is worked around in the same way as the
* Intel problem.
#define TASK_SIZE_MAX ((1UL << __VIRTUAL_MASK_SHIFT) - PAGE_SIZE)
#define IA32_PAGE_OFFSET ((current->personality & ADDR_LIMIT_3GB) ? \
0xc0000000 : 0xFFFFe000)
#define TASK_SIZE (test_thread_flag(TIF_ADDR32) ? \
IA32_PAGE_OFFSET : TASK_SIZE_MAX)
在具有48位虚拟地址空间的处理器上，__VIRTUAL_MASK_SHIFT值为47。
请注意，TASK_SIZE根据当前进程是32位32位，64位32位还是64位64位来指定。对于32位进程，将保留两个页面。一个用于vsyscall页面，另一个用作保护页面。本质上，无法取消映射vsyscall页面，因此用户地址空间的最高地址实际上是0xFFFFe000。对于64位进程，保留一个保护页。这些页面仅在64位Intel和AMD处理器上保留，因为仅在这些处理器SYSCALL上使用了该机制。
这是在中执行的检查get_unmapped_area：
if (addr > TASK_SIZE - len)
return -ENOMEM;