64位linux上32位进程的地址空间 [英] 32-bit process’s address space on 64-bit linux

问题描述

在此答案中，作者指出: With the 64-bit x86_64 kernel, a 32-bit process can use the entire 4GB address space, except for a couple pages (8KB) at the end of the 4GB address space which are managed by the kernel.

In this answer author states: With the 64-bit x86_64 kernel, a 32-bit process can use the entire 4GB address space, except for a couple pages (8KB) at the end of the 4GB address space which are managed by the kernel.

此内核管理的内存的用途是什么?不是应该在内核空间中，以防止用户意外损坏吗?

What is the purpose of this kernel-managed memory? Shouldn’t it be in the kernel space, to prevent accidental corruption by the user?

推荐答案

引用内核源代码:"内核指针具有冗余信息，因此我们可以使用一种方案，在该方案中可以返回错误代码或[. ..]具有相同返回值的指针."

Citing the kernel source: "Kernel pointers have redundant information, so we can use a scheme where we can return either an error code or a [...] pointer with the same return value."

值-1 ..- 4095(在32位模式下映射到0xfffff000–0xffffffff)保留用于内核级errno值. 0xffffe000–0xffffefff的其他4KB保留给vsyscall vdso魔术页面使用，但是由于许多月亮可以重新分配vdso页面，因此该区域可能未被填充，也就是说，/proc/*/maps中的[stack]条目结束于无论[vdso]是否映射到0xffffe000或其他位置，始终为0xffffdfff.

The values -1..-4095 (mapping to 0xfffff000–0xffffffff in 32-bit mode) are reserved for kernel-level errno values. The other 4KB from 0xffffe000–0xffffefff are held free for the vsyscall vdso magic page, but since the vdso page is relocatable since many moons, this area remains potentially unpopulated, that is to say, the [stack] entry in /proc/*/maps ends at 0xffffdfff always regardless of whether [vdso] is mapped at 0xffffe000 or elsewhere.

这篇关于64位linux上32位进程的地址空间的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！