Mechanism: Limited Direct Execution

The Core Idea of Direct Execution

To let user programs run as fast as possible the kernel merely creates a process descriptor, allocates an address space, loads the executable image and then transfers control to the program entry point. From that moment instructions execute natively on the real CPU with virtually no interpretation or emulation overhead.

Hardware Modes that Limit Dangerous Operations

Native execution is fast yet a process might issue disk I/O or monopolize the processor forever. The processor therefore supplies a user mode in which privileged instructions raise an exception. The kernel itself runs in kernel mode and may execute anything. When a service is required the user program must enter the kernel through a well-defined trap.

Trap Tables Guarantee Safe Control Transfer

At boot the kernel informs the hardware of the addresses of every exception handler, forming a trap table. When a trap occurs the hardware automatically saves user registers and jumps to the corresponding table entry. After finishing its work the kernel executes a return-from-trap instruction that restores user state and lowers privilege. A user program can never choose its own kernel jump target.

Pitfalls

• Treating a system call as an ordinary C function call and overlooking the hidden trap instruction inside it
• Thinking a user program is allowed to jump to an arbitrary address inside the kernel

Minimum C11 · complete program · Download .c

#include <stdio.h>

int main(void) {
    puts("OS creates process and switches to user mode");
    puts("User process runs natively");
    puts("User issues trap for restricted operation");
    puts("Hardware saves state and enters kernel mode");
    puts("Kernel handles system call then returns from trap");
    puts("User process resumes until it exits");
    puts("OS reclaims resources");
    return 0;
}

Compile locally

gcc -std=c11 -Wall -Wextra -Wpedantic -Werror ostep-06-direct-execution.c -o example && ./example

Expected result

OS creates process and switches to user mode
User process runs natively
User issues trap for restricted operation
Hardware saves state and enters kernel mode
Kernel handles system call then returns from trap
User process resumes until it exits
OS reclaims resources

CHECK YOUR UNDERSTANDING

Close the answer. Explain it.

If the hardware provided no user/kernel mode switch, could the OS still virtualize the CPU both efficiently and safely? Explain.

Check the sources

• OSTEP chapter PDF

Drafts and official chapters change. The version mark is only the example’s minimum.