内核空间是否映射到 Linux x86 上的用户空间? [英] Is kernel space mapped into user space on Linux x86?

问题描述

似乎在Windows 32位上，内核会从总共4G的用户虚拟内存空间中预留1G的虚拟内存，并将部分的内核空间映射到这1G空间中.

所以我的问题是:

1. 在 32 位 Linux 上有没有类似的情况?
2. 如果是这样，我们如何才能看到整个内存布局?

我觉得

cat/proc/pid/map

只能看到某个进程的用户空间布局..

谢谢！

解决方案

其实在 32 位 Windows 上，没有 /3G 启动选项，内核被映射到线性地址的前 2GB空间，为用户进程留出 2GB.

Linux 做了类似的事情，但它将内核映射到前 1GB 的线性空间，从而为用户进程留出 3GB.

我不知道您是否可以仅使用/proc 文件系统查看整个内存布局.在我为学生设计的实验室中，我创建了一个微型设备驱动程序，允许用户查看物理内存地址，并获取多个控制寄存器的内容，例如 CR3(目录页基地址).

通过使用这两个操作，可以遍历当前进程的目录页面(正在执行此操作的那个)，并查看哪些页面存在，哪些页面属于用户和内核，或者只是由内核，哪些是读/写或只读等.有了这些信息，他们必须显示一个显示内存使用情况的映射，包括内核空间.

看看这个 PDF.这是我们在课程中所做的所有实验的编译版本.http://www.atc.us.es/asignaturas/tpbn/PracticasTPBN2011.pdf

在 PDF 的第 36 页(文档的第 30 页)，您将看到内存映射的样子.这是实验 #3 中练习 #3.2 的结果.

文本是西班牙语，但我相信如果有你无法理解的东西，你可以使用翻译器或类似的东西.本实验假设学生之前已经阅读了分页系统的工作原理以及如何解释目录和页面条目的布局.

地图是这样的.一个 16x64 的块.块中的每个单元格代表当前进程虚拟地址空间的 4MB.地图应该是立体的，因为有 4MB 的区域由具有 1024 个条目(页面)的页表描述，并且可能不是所有页面都存在，但为了保持地图清晰，练习要求用户折叠这些区域，显示描述当前页面的第一个页面条目的内容，希望该页表中的所有后续页面共享相同的属性(这可能是也可能不是真的).​​

此映射用于内核 2.6.X.其中不使用PAE，使用PSE(PAE 和PSE 是来自控制寄存器的两个位域CR4).PAE 启用 2MB 页面，PSE 启用 4MB 页面.4KB 页面始终可用.

<预><代码>.: PDE 不存在，或页表为空.X : 4MB 页面，主管.R : 4MB 页面，用户，只读.* : 4MB 页，用户，读/写.x :页表，至少有一个条目描述一个主管页.r :页表，至少有一个条目描述用户页面，只读.+ :页表，至少有一个条目描述用户页面，读/写......................................................…………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………….....................................+................................………………xXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX……………………xx

可以看到有3GB的巨大内存空间，在这种情况下几乎是空的(该进程只是一个小C应用程序，使用不到4MB，全部包含在一个页表中，其第一个当前页面是只读页面，假定为程序代码的一部分，或者可能是静态字符串).

在3GB边界附近有两个小区域read/write，可能属于用户程序加载的共享库.

最后 4 行(256 个目录条目)几乎都属于内核.实际存在和使用的条目有 224 个.这些映射物理内存的前 896MB，它是内核所在的空间.在内存超过 896MB 的系统中，内核使用最后 32 个条目访问超过 896MB 标记的物理内存.

It seems that on Windows 32 bit, kernel will reserve 1G of virtual memory from the totally 4G user virtual memory space and map some of the kernel space into this 1G space.

So my questions are:

1. Is there any similiar situation on 32 bit Linux?
2. If so, how can we see the whole memory layout ?

I think

cat /proc/pid/map

can only see the user space layout of certain process..

Thank you!

解决方案

Actually, on 32-bit Windows, without the /3G boot option, the kernel is mapped at the top 2GB of linear address space, leaving 2GB for user process.

Linux does a similar thing, but it maps the kernel in the top 1GB of linear space, thus leaving 3GB for user process.

I don't know if you can peek the entire memory layout by just using the /proc filesystem. For a lab I designed for my students, I created a tiny device driver that allows a user to peek at an physical memory address, and get the contents of several control registers, such as CR3 (directory page base address).

By using these two operations, one can walk through the directory page of the current process (the one which is doing this operation) and see which pages are present, which ones are owned by the user and the kernel, or just by the kernel, which ones are read/write or read only, etc. With that information, they have to display a map showing memory usage, including kernel space.

Take a look at this PDF. It's the compiled version of all the labs we did in my course. http://www.atc.us.es/asignaturas/tpbn/PracticasTPBN2011.pdf

On page 36 of PDF (page 30 of the document) you will see how a memory map looks like. This is the result of doing exercise #3.2 from lab #3.

The text is in spanish, but I'm sure you can use a translator or something like that if there are things you cannot understand. This labs assumes the student has previously read about how the paging system works and how to interpret the layout of the directory and page entries.

The map is like this. A 16x64 block. Each cell in the block represents 4MB of the current process virtual address space. The map should be tridimensional, as there are 4MB regions that are described by a page table with 1024 entries (pages), and not all pages may be present, but to keep the map clear, the exercise requires the user to collapse these regions, showing the contents of the first page entry that describes a present page, in the hope that all subsequents pages in that page table share the same attributes (which may or may not be actually true).

This map is used with kernels 2.6.X. in which PAE is not used, and PSE is used (PAE and PSE being two bit fields from control register CR4). PAE enables 2MB pages and PSE enables 4MB pages. 4KB pages are always available.

. : PDE not present, or page table empty.
X : 4MB page, supervisor.
R : 4MB page, user, read only.
* : 4MB page, user, read/write.
x : Page table with at least one entry describing a supervisor page.
r : Page table with at least one entry describing an user page, read only.
+ : Page table with at least one entry describing an user page, read/write.

................................r...............................
................................................................
................................................................
................................................................
................................................................
................................................................
................................................................
................................................................
................................................................
................................................................
................................................................
...............................+..............................+.
xXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXxX
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX..x...........................xx

You can see there is a vast space of 3GB of memory, almost empty in this case (the process is just a little C application, and uses less than 4MB, all contained in a page table, whose first present page is a read only page, assumed to be part of the program code, or maybe static strings).

Near the 3GB border there are two small regions read/write, which may belong to shared libraries loaded by the user program.

The last 4 rows (256 directory entries) belong almost all of them to the kernel. There are 224 entries which are actually being present and used. These maps the first 896MB of physical memory and it's the space in where the kernel lives. The last 32 entries are used by the kernel to access physical memory beyond the 896MB mark in systems with more than 896MB RAM.

这篇关于内核空间是否映射到 Linux x86 上的用户空间?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！