When do we jump into kernel part of our process virtual memory other than when we use system calls? (In Linux)

Question

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.)

Answer 1

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).

Answer 2

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).

Answer 3

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.