24

I found a similar question but still it doesn't answer my questions Do the virtual address spaces of all the processes have the same content in their "Kernel" parts?

  1. First off, considering user processes don't have access to this part and I guess if they try to access it, it would lead to an error, then why even include this part in the user process virtual space? Can you guys give me a real life scenario of this part being essential and useful?

  2. Also, one more question is I always thought the kernel part of memory is dynamic, meaning it might grow for example when we use dynamic libraries in our programs, so is it true? If so, then how can the OS determine how big the size of kernel is in the virtual space of our processes?

  3. And when our kernel in physical memory grows or changes, does the same effect happens in the kernel part of virtual memory for all the processes? Is the mapping of this virtual kernel to real kernel a one to one mapping?

enter image description here

John P
  • 1,103
  • Tim also used that diagram at https://unix.stackexchange.com/questions/466389/ , where I pointed out that it was incomplete (in the application-mode part), and at https://unix.stackexchange.com/questions/466443/ . – JdeBP Sep 29 '18 at 09:08
  • @JdeBP also what about Dynamic libraries? in some pictures there is a dynamic library between stack and heap! https://i.stack.imgur.com/Dsv4b.jpg – John P Sep 29 '18 at 09:14
  • What about libraries? What specifically do you want to know about them? – Stephen Kitt Sep 29 '18 at 09:40
  • @StephenKitt i want to know if there is a dynamic library part between heap and stack in linux or not – John P Sep 29 '18 at 10:00
  • That doesn’t have much to do with the kernel, but yes, on 32-bit x86 there’s an area for dynamic libraries between the heap and the stack. It’s really the mmap area; dynamic libraries are mmapped in. – Stephen Kitt Sep 29 '18 at 10:05
  • @StephenKitt so basically the picture in my question is wrong too, is there any complete and reliable picture for linux process virtual space? – John P Sep 29 '18 at 10:07
  • This question has a different diagram (contrary to JdeBP’s comment above) which is somewhat more accurate for the user-space side of things. There is no doubt a complete diagram somewhere on the Internet but I don’t have a link handy. – Stephen Kitt Sep 29 '18 at 11:45

2 Answers2

19

  1. The kernel mapping exists primarily for the kernel’s purposes, not user processes’. From the CPU’s perspective, any physical memory address which isn’t mapped as a linear address might as well not exist. But the CPU does need to be able to call into the kernel: to service interrupts, to handle exceptions... It also needs to be able to call into the kernel when a user process issues a system call (there are various ways this can happen so I won’t go into details). On most if not all architectures, this happens without the opportunity to switch page tables — see for example SYSENTER. So at minimum, entry points into the kernel have to be mapped into the current address space at all times.

  2. Kernel allocations are dynamic, but the address space isn’t. On 32-bit x86, various splits are available, such as the 3/1 GiB split shown in your diagram; on 64-bit x86, the top half of the address space is reserved for the kernel (see the memory map in the kernel documentation). That split can’t move. (Note that libraries are loaded into user space. Kernel modules are loaded into kernel space, but again that only changes the allocations, not the address space split.)

  3. In user mode, there is a single mapping for the kernel, shared across all processes. When a kernel-side page mapping changes, that change is reflected everywhere.

    When KPTI is enabled, the kernel has its own private mappings, which aren’t exposed when running user-space code; so with KPTI there are two mappings, and changes to the kernel-private one won’t be visible to user-space (which is the whole point of KPTI).

    The kernel memory map always maps all the kernel (in kernel mode when running KPTI), but it’s not necessarily one-to-one — on 64-bit x86 for example it includes a full map of physical memory, so all kernel physical addresses are mapped at least twice.

Stephen Kitt
  • 434,908
  • Thanks for answer, but i didn't get the last part, what do you mean kernel physical addresses are mapped twice? i just want to understand what is inside this kernel part of virtual memory, like that 1gb in 32 bit, i mean why would that be the entire kernel anyways? shouldn't only the O.S services that processes might need be there and not the entire kernel? – John P Sep 29 '18 at 16:35
  • 2
    On 64-bit x86, the kernel memory map includes a direct mapping of all physical memory, so everything in memory appears there; it also includes separate mappings for the kernel, modules etc., so the physical addresses containing the kernel appear in at least two different mappings (the direct physical mapping and the various kernel mappings). – Stephen Kitt Sep 29 '18 at 19:42
  • 3
    As to why the entire kernel is mapped, when KPTI isn’t enabled, it’s mainly because it’s simpler that way. The kernel consists pretty much entirely of OS services that processes might need, either because they implement system calls and their supporting infrastructure (file systems etc.), or because they provide hardware support (device drivers including interrupt handlers etc.). The kernel can’t know in advance what a process is going to use. – Stephen Kitt Sep 29 '18 at 19:44
  • @StephenKitt How do you know so much? – Suraj Jain Dec 21 '19 at 18:28
  • @StephenKitt Does Kernel allocations are dynamic means dynamic mapping between 'virtual kernel space' and 'physical kernel memory space'? – obanadingyo Oct 13 '22 at 02:36
  • @obanadingyo that depends on what you mean by dynamic. Kernel memory is pinned and can’t be swapped out, so once it’s allocated, neither the virtual address nor the physical address change. However there’s no pre-assigned mapping of physical to virtual addresses (apart from the big physical memory mapping on some architectures), so code allocating memory in the kernel can’t know ahead of time what addresses it’s going to get. – Stephen Kitt Oct 14 '22 at 10:40
1

Another small tip for more common understanding by definition of kernel it should be active all the time to perform administrative services and to provide services to user applications. This activeness is practically achieved by logically binding the kernel in every process.

This makes sense also, consider multiple processes are running in a single processor machine environment, and also consider that the process structure does not contains the kernel mapping. As there is only one processor, once a process is scheduled for running, it definitely means that the kernel is not active, as the CPU is occupied by the process, furthermore we have assumed that there is no mapping of kernel available in the process. Now the logical question is how would the kernel perform its services than, the solution is to map kernel in every process.

That's how I think every human being has a mapping to the creator.

Abdullah
  • 111