This is a follow up question from my previous question.

Based on the answer, a system call is an example of when we jump into kernel part of virtual memory of our process.

  1. What are other examples of a normal process (non kernel) using this part of virtual memory other than system calls? like is there any function call that directly jumps into this kernel part or..?

  2. When we jump into this section of memory, does the processor automatically set the kernel mode bit to 1 in order for our process to access this part or there is no need to set this bit?

  3. Does all of the execution inside of this kernel part happen without any need for context switching to a kernel process?

(I didn't want to ask these follow up questions on comments so I opened another thread.)

enter image description here

  1. Processes running in user mode don’t have access to the kernel’s address space, at all. There are a number of ways for the processor to switch to kernel mode and run kernel code, but they are all set up by the kernel and happen in well-defined contexts: to run a system call, to respond to an interrupt, or to handle a fault. System calls don’t involve calling into kernel code directly; they involve an architecture-specific mechanism to ask the CPU to transfer control to the kernel, to run a specific system call, identified by its number, on behalf of the calling process. LWN has a series of articles explaining how this works: Anatomy of a system call part one, part two, and additional content.

    If a process attempts to access memory in the kernel’s address space, it will switch to kernel mode, but as a result of a fault; the kernel will then kill the process with a segmentation violation (SIGSEGV).

    On 32-bit x86, there is a mechanism to switch to kernel mode using far calls, call gates; but Linux doesn’t use that. (And they rely on special code segment descriptors rather than calling into kernel addresses.)

  2. See above: you can’t jump into kernel memory. In the circumstances described above, when transitioning to kernel mode, the CPU checks that the transition is allowed, and if so, switches to kernel mode using whichever mechanism is appropriate on the architecture being used. On x86 Linux, that means switching from ring 3 to ring 0.

  3. Transitioning to kernel mode doesn’t involve a change of process, so yes, all this happens without a context switch (as counted by the kernel).

  • So overall cpu jumps into kernel space of a process for 3 things : 1.to run a system call 2. to respond to an interrupt 3. to handle a fault; correct? (just want to make sure i know all the situations were our CPU might need to jump into this section of our process virtual memory)
    – John P
    Oct 8 '18 at 8:59
  • 1
    Yes, that’s exactly what I wrote ;-). Oct 8 '18 at 9:04
  • 1
    On x86 you can see all the entry points in the kernel in arch/x86/entry: entry_32.S for 32-bit x86, entry_64_compat.S for 32-bit compatibility on 64-bit x86, and entry_64.S for 64-bit x86. Oct 8 '18 at 9:08

1 & 2. No, a user program cannot simply use a jump instruction to enter kernel memory. It is not allowed to do so. The CPU does not automatically set the "kernel bit" to allow such a jump to succeed... (maybe some CPU has such a feature, but a secure Linux port would disable this feature)

...Actually, since you are accessing a page in a way you do not have permission to do, you will enter the kernel :-). It enters in a controlled fashion, it works very similar to a system call, but we call it a "page fault". The CPU will provide details of the access to the kernel. With the type of access you describe, the kernel will treat it as an error in your program :-). It will send a fatal signal to your program (SIGSEGV).

  • So what happens when a normal process wants to do a JMP into a function inside of kernel? or when it wants to jmp into the code of a system call? if it cannot access that part then what happens and how can it use that function?
    – John P
    Oct 8 '18 at 6:45
  • @JohnP lwn.net/Articles/604287
    – sourcejedi
    Oct 8 '18 at 7:24

Technically, kernel memory can be mapped into processes,, unreadable, read only or read-write, and possibly even executed by processes by jumping into code stored in that memory. This can be a technique for increasing the speed of some syscalls where it is safe to run code to handle the syscall in the process rather than in the kernel. It can also include data such as a memory address containing a clock value provided by the kernel so a process doesn't have to interrupt so the system can enter the kernel.

Its also possible for processes to enter system calls by interrupt into the kernel through INT 0x80, this is what many assembly programmers are familiar with, but it is certainly not the only mechanism that can be provided by the kernel. There is no hard rule that a kernel and user address spaces have to be completely seperate.

Regardless of what approaches Linux uses, it is certainly technically feasible to put kernel code and data in processes. Linux does put kernel memory in process routinely as well, for performance reasons related to context switches and the TLB, as well, but since many areas of the kernel are sensitive, they are usually not readable by the process.

  • I believe that what you are describing here would result in a segmentation fault. A program jumping into kernel space is disallowed for obvious reasons. You might want to mention this. It's my understanding that it IS a "hard rule" that kernel space is protected from illegal access.
    – Elder Geek
    Apr 21 '21 at 16:04
  • The question is about virtual memory, i.e. address space, and the kernel’s address space is never accessible from user space. On 64-bit x86 that’s even enforced by the architecture (the top bit of canonical addresses). What you’re referring to at the start of your answer is the vDSO, and that involves mapping certain pages of the kernel’s allocated memory (pages, not addresses) into processes’ regular address space. Apr 21 '21 at 16:14

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.