Limited direct execution: Difference between revisions

From Rice Wiki
No edit summary
 
(One intermediate revision by the same user not shown)
Line 4: Line 4:
[[File:OSTEP 6.1.png|thumb|OSTEP: Direct Execution Protocol (Without Limits)]]
[[File:OSTEP 6.1.png|thumb|OSTEP: Direct Execution Protocol (Without Limits)]]
Let's first talk about the simpler sibling of limited direct execution. '''Direct execution''' (without limits) simply allows programs to run on the CPU.
Let's first talk about the simpler sibling of limited direct execution. '''Direct execution''' (without limits) simply allows programs to run on the CPU.
This approach, while fast and simple, has problems over ''control'':
* '''Restricted operation:''' How does the OS stop processes from doing things we don't want it to do?
* '''Switching between processes:''' How does the OS stop an executing process, which is needed for time sharing?
== Limiting operations ==
There are many things that a user may not want a process to do. For example, performing I/O operations to disks, demanding more system resources, etc. Many functions that we take for granted would be impossible on a direct execution system, an example being limiting disk access to certain programs/users with file permissions.
To limit sensitive operations, most operating systems have two modes: '''kernel mode''' and '''user mode'''. In kernel mode, all instructions are fair game. In user mode, certain sensitive operations such as I/O and process/resource management would raise an exception.
We want to limit a process' control but still allow them to perform necessary functions. This is done through '''system calls'''. When a user program wants to access restricted resources, they make a system call, which then use the '''trap''' instruction to elevate to kernel mode. The kernel then checks the necessary permissions.
[[Category:Operating System]]
[[Category:Operating System]]

Latest revision as of 18:08, 4 October 2024

Limited direct execution is a technique of allowing programs to partially execute on the CPU directly. This ensures the two necessities of CPU virtualization: performance and control.

Direct execution

OSTEP: Direct Execution Protocol (Without Limits)

Let's first talk about the simpler sibling of limited direct execution. Direct execution (without limits) simply allows programs to run on the CPU.

This approach, while fast and simple, has problems over control:

  • Restricted operation: How does the OS stop processes from doing things we don't want it to do?
  • Switching between processes: How does the OS stop an executing process, which is needed for time sharing?

Limiting operations

There are many things that a user may not want a process to do. For example, performing I/O operations to disks, demanding more system resources, etc. Many functions that we take for granted would be impossible on a direct execution system, an example being limiting disk access to certain programs/users with file permissions.

To limit sensitive operations, most operating systems have two modes: kernel mode and user mode. In kernel mode, all instructions are fair game. In user mode, certain sensitive operations such as I/O and process/resource management would raise an exception.

We want to limit a process' control but still allow them to perform necessary functions. This is done through system calls. When a user program wants to access restricted resources, they make a system call, which then use the trap instruction to elevate to kernel mode. The kernel then checks the necessary permissions.