- What would happen if a kernel-level process sets some of its memory
mprotectand another kernel-level process tries to read one of these protected pages?
- What is the equivalent of
mprotectin windows? What are the main differences?
It depends on what you mean by "kernel process".
In Linux, each process has its own address space, which is embodied by the MMU and its configuration table. Roughly speaking, at any one time, the MMU is configured to find information about pages (where each page from the address space is in RAM, if it is present at all, and the access rights) in tables located at some address in physical RAM (details vary depending on the architecture, but in 32-bit x86 the CR3 register is used for that). When the CPU switches from one process to another, it changes that configuration (i.e. before granting control to any process, the CPU loads the CR3 register with the right value for that process).
This means that if a process uses
Note that when a process does a system call, the CPU jumps into the kernel space and obtains kernel-level privileges, but the MMU is not affected (well, in fact it can be, depending on the architecture and kernel version; normally, each page is mapped twice, with one mapping accessible only with kernel privileges, so that the kernel may write into RAM which is, from the point of view of the process, absent or read-only; however, things can become a bit more complex on 32-bit x86 because the double-mapping implies a restriction to at most 2 GB of address space per process, and recent kernels have some tricks to go to 4 GB per process, basically by switching MMU mappings when entering the kernel; let's not confuse the situation any further with such details). So the code for the system call executes with the mapping as the calling process sees it (albeit with kernel privileges).
Kernel threads, sometimes known as kernel processes, are something different. These are processes without RAM. They run with kernel-level privileges and occupy a slot in the scheduler, but they don't have an address space of their own. Being threads, they are occasionally granted the CPU (that's the point). However, since they don't have an address space, they don't incur a MMU table switch when they are activated, which is a blessing because MMU table switches are expensive (because of TLB flushes). So kernel threads basically run in the address space of whatever normal process was last running.
If a kernel thread does a
Moreover, kernel threads run with kernel privileges, which means that they can do more than normal applications. They tend to be able to read
Summary: if it is allowed at all by the kernel, it seems most unwise to fiddle with userland RAM from kernel threads.