8

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.

Improve this question
1
  • 1
    There are some good questions here but could you split them up into more specific questions with one major topic per question? Commented Dec 15, 2014 at 11:05

1 Answer 1

Reset to default
5

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.

Improve this answer
2
  • 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? Commented Dec 16, 2014 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. Commented Dec 17, 2014 at 10:27

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.