Ch.

6 - Mechanism - Limited Direct Execution

#limitedDirectExecution #operatingSystems

Terminology:

Limited Direct Execution

Trap Table
Kernel
Time Sharing
Trap Handlers
System-Call Number
Protection
Privileged
Secure
Cooperative Approach
System Calls
Yield
Reboot The Machine
Interrupt Handler
Timer Interrupt
Scheduler
Context Switch
Switches Context
Concurrency
Disable Interrupts
Locking Schemes
Baby Proofing
Kernel Mode
User Mode
Kernel Stack

Limited Direct Execution is how the OS allows different agents of the OS to

access and call kernel functions and memory spaces.

To execute a system call, a program must execute a special trap instruction.

This instruction simultaneously jumps into the kernel and raises the privilege

level to kernel mode; one in the kernel, the system can no perform whatever

privileged operations are needed(if (allowed), and thus do the required work for the calling
process.

When finished, the OS calls a special return-from-trap instruction, which

returns into the calling user program while simultaneously reducing the

priveledge level back to user mode.

The hardware needs to be careful when executing a trap, in that it must make

sure to save enough of the caller's registers in order to be able to return

correctly when the OS issues the return-from-trap instruction.

on x86 for example, the processor will push the program counter, flags, and a

few other registers onto a per-process kernel stack; the return-from-trap will

pop these values off the stack and resume execution of the user-mode program.

Other hardware systems use different conventions, but the basic concepts are
similar across platforms.

A Trap Table is a collection of calls that transfer control over to the

kernel.

In order for the OS to regain control of the CPU and therefor be able to run

the OS procedures the calls from programs are ended and they thus return the

control over to the OS. Another way the control comes back to the OS is if the

program tries to do something illegal. When this is triggered, the OS is

called and takes control of the program usually terminating the offending

process.

Crux of The Problem 1

Problem #1 Restricted Operations

How does the trap know which code to run inside the OS?

Clearly, the calling process can't specify an address to jump to(as you would

when making a procedure call); doing so would allow program to jump anywhere

into the kernel which clearly is a Very Bad Idea. Thus the kernel must

carefully control what code executes upon a trap.

The kernel does so by setting up a trap table at boot time. When the

machine boots up, it does so in privileged(kernel) mode, and thus is free to

configure machine hardware as need be. One of the first things the OS thus

does it to tell the hardware what code to run when certain exceptional events

occur. For example, what code should run when a hard-disk interrupt takes

place, when a keyboard interrupt occurs, or when a program makes a system

call? The OS informs the hardware of the locations of these trap handlers,

usually with some kind of special instruction. Once the hardware is informed,

it remembers the location of theses handlers until the machine is next

rebooted, and thus the hardware knows what to do(what code to jump to) when

system calls and other exceptional events take place.

To specify the exact system call, a system-call number is usually assigned to

each system call. The user code calls a system call number and then the OS

performs the jump to where the code for the system-call is, only if it is a

valid system-call number.

This level of indirection serves as a form of protection; user code cannot

specify an exact address to jump to, but rather must request a particular

service via a number.

Executing the code to tell the hardware where the trap tables are located is

a privileged operation and the hardware won't let the user code execute this

operation. The OS would terminate the offending program if it tried to do

this.

pg. 6

Although we have done a good job at making our OS secure, there are still

gaps we need to look for. The OS needs to check and validate the arguments

passed in the system calls. In general, the OS needs to treat user input with

great suspicion.

There are two phases in the LDE (limited direct execution) protocol. In the

first, at boot time, the kernel initializes the trap table and the CPU

remembers its location for subsequent use.

In the second,(when running a process) the kernel sets up a few things before

using a return-from-trap instruction to start the execution of the process.

It switches the CPU to user-mode and begins running the process. When the

process wishes to trap into the OS it does so and when it is done it uses the

-return-from-trap to the process. The process then ends its execution and

calls the exit() system call, which traps into the OS. At this point the OS

cleans up and it is done.

Problem #2 Switching Between Processes

The Crux: How to regain control of the CPU:

How can the operating system regain control of the system so that it can switch between
processes?

A cooperative approach: Wait for System Calls

In this style the OS trusts the processes of the system to behave reasonably. Processes that
fun for too long are assumed to give up the CPU so that the OS can decide to run some other
task.

How does a friendly process give up the CPU?

Most processes transfer control of the CPU by making system calls, for example to read or
write a file, or to send a message to another machine.Systems like this often include an explicit
yield call which transfers control to the OS so it can run other processes.

In Applications the OS also returns to control when an illegal operation is performed such as
dividing by 0 or if the application is trying to access forbidden memory spaces. It will generate a
trap which would return control to the OS.

So in sum, the OS regains control through system calls or illegal operations.

Isn't this passive approach less than ideal?

What happens if the program ends up in an infinite loop and never makes the system call?
What happens then?

A non-cooperative approach:

without some help from the hardware it turns out that there is not much the OS can do if a
process never makes a system call and thus return control to the OS. In fact, in the cooperative
approach your only recourse when a process gets stuck in an infinite loop is to resort the age-
old solution to all problems in computer systems: reboot the machine.

The Crux

How can the OS gain control of the CPU even if processes are not being cooperative?

What can the OS do to ensure a rogue process does not take over the machine?

By using a timer Interrupt. A timer device can be programmed to raise an interrupt every so
many milliseconds; when the interrupt is raised the currently running process is halted, and a
pre-configured interrupt handler in the OS runs. At this point, the OS has regained control of
the CPU, and thus can do what it pleases: stop the current process, and start a different one.

As we discussed before with system calls, the OS must inform the hardware of which code to
run when the timer interrrupt occurs; thus, at boot time, the OS does exactly that. Second, also
during the boot sequence, the OS must start the timer, which is of course a privileged operation.
Once the timer has begun, the OS can thus feel safe in that control will eventually be returned
to it, and thus the OS is free to run user programs. The timer can also be turned off(also a
privelegaed operation).

Note that the hardware has some responsibility when an interrupt occurs, in particular to save
enough og the state of the program that was running when the interrupt occured such that a
subsequent return-from-trap instruction will be able to resume the running program correctly.

Saving and Restoring Context

Now that the OS has regained control, a decision has to be made: whether to continure running
the currently-running process. or switch to a different one. This decision is made by a part of the
operating system known as the scheduler.