3
$\begingroup$

Let's say we have a fictional operating system in the user mode. Whenever an interrupt or a trap occurs, the os would switch to the Kernel mode jumping to the address determined from the interrupt vector. A malicious user could take advantage of the loophole by executing a malicious program in the kernel mode.

Why is it dangerous ? What could have the user possibly done to achieve this and what kind of remedy would you suggest for the loop hole ?

Improve this question
$\endgroup$
1
  • 3
    $\begingroup$ Your hypothetical setup is a bit too hypothetical. It's the CPU itself that switches to the code pointed to by the interrupt vector when an interrupt happens. The vectors can only be changed with privileged instructions (on x86). It's not clear either what your hypothetical loophole is, so there really isn't anything to fix. If you had a loophole allowing userspace applications to execute privileged instructions, well, that's bad. $\endgroup$
    – Mat
    Commented Jan 27, 2013 at 16:21

2 Answers 2

Reset to default
5
$\begingroup$

The malicious user has to first get the malicious code into kernel space somehow. User and kernel address spaces often look contiguous under linux and various unixes, but user space isn't mapped into kernel space, and vice versa. Some variations of Unix (the Masscomp system, as I recall) made this more explicit by having user space and kernel space start at 0x00000000. So, that's the first problem: code at 0x0804890c (or where ever) writeable by the user doesn't exist in the kernel's address space.

Secondly, the malicious user would have to have the ability to change the interrupt vector. This vector conceptually could live in either kernel or user space, but probably resides in kernel space. If the interrupt vector resides in kernel space, the user doesn't have write access. If the interrupt vector resides in user space, it's marked read-only, and the addresses in it point to code in kernel space. Which is why problem (1) above for the malicious user exists.

Improve this answer
$\endgroup$
1
  • 1
    $\begingroup$ In the sense of being in page tables, kernel space usually is "mapped" to user space. It is however protected so the user-space code can't read nor write it. $\endgroup$
    – Jan Hudec
    Commented Jan 28, 2013 at 9:05
1
$\begingroup$

The details depend on the processor architecture, but generally speaking, when an interrupt is raised:

  • The CPU saves some registers (at least the current program counter and an indication of the current processor mode).
  • The CPU switches to a privileged mode.
  • The CPU reads a pointer value from virtual memory at a predefined location (the interrupt vector).
  • The CPU branches to that address.

It's up to the operating system designer to ensure that use mode code cannot change the interrupt vector and that the interrupt vector points to a location that can only be modified by privileged code. The page containing the interrupt vector, the code page that the interrupt vector points to, and of course the virtual memory tables, must be modifiable only by privileged code. If there was a way for the currently-running user mode code to affect what is executed on an interrupt, that would be a major bug in the kernel.

Improve this answer
$\endgroup$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.