I don't know much about Linux kernel, and I have some questions.

  1. What is the main purpose of separating kernel memory from user-space memory? To make sure that a user application cannot do anything bad to the kernel?

  2. How many ways are there for a user-level application to transfer control to the kernel? What I can come up with include (1) invoking a system call, (2) mapping memory to the kernel (but I think mmap() is also a system call), and (3) loading a kernel module (but I guess lsmod also invokes some system call). Am I correct? Are there any other ways that I missed?

  3. How many ways to attack the kernel? May I have some brief details about them?

  4. If I get the root privilege, does it mean that I completely control the kernel? Namely, I can do whatever I want with the kernel and hardware? Or I still have limited power on the kernel?

I'd really appreciate it if someone can help me figure out the answer to these questions.

closed as too broad by a CVn, bsd, Anthon, Mat, Networker Dec 15 '14 at 10:58

Please edit the question to limit it to a specific problem with enough detail to identify an adequate answer. Avoid asking multiple distinct questions at once. See the How to Ask page for help clarifying this question. If this question can be reworded to fit the rules in the help center, please edit the question.

  • 1
    There are some good questions here but could you split them up into more specific questions with one major topic per question? – Caleb Dec 15 '14 at 11:05

I will try to answer questions as briefly as possible. The questions you are asking are usually addressed in introductory operating systems courses at universities but I will assume you have not taken such a course.

  1. Memory isolation for userspace processes is very desirable - not only to protect the kernel from malicious userspace programs, but also to protect userspace programs from each other. This is usually referred to as Virtual Memory. It also makes it easier to implement paging, which is desirable for other reasons as well (simpler fragmentation, simpler linkers/loaders etc.).

  2. Interrupts (not all of which are in control of a user-level application). Giving up processor also takes "control" away form the process (e.g. wait etc. which are also system calls). The kernel might itself decide to unschedule an application.

  3. That is a very broad question. Kernel with badly implemented system calls is vulnerable. Ability to write to physical memory would be another way. There are other vulnerabilities that can arise from badly implemented instructions (e.g. sysret vulnerability in Intel processors).

  4. Root privileges is not the same as kernel privileges. An application running as root user is still using virtual memory, still has to make system calls, still has to obey the other rules that any user-level application has to.

If you want me to provide more details on some of the answers, let me know.

If someone can improve some of the answers, please feel free to point it out.

  • Thank you for your reply. You said "Interrupts (not all of which are in control of a user-level application).", meaning that only software interrupts are in control of user-level, while hardware interrupts are not. Is it correct? – hebothu Dec 16 '14 at 4:01
  • I believe the userspace has to somehow ask the kernelspace to let it handle some of the interrupts. So the kernel is basically still in control of the interrupts. In particular, the kernel is still handling the interrupts and passes them on to userspace if a userspace application cares to receive it. Lookup Linux UIO. – mtahmed Dec 17 '14 at 10:27

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