1. The Kernel Abstraction

2. Main Points Process concept Dual-mode operation: user vs. kernel
A process is an OS abstraction for executing a program with limited privileges
Dual-mode operation: user vs. kernel
Kernel-mode: execute with complete privileges
User-mode: execute with fewer privileges
Safe control transfer
How do we switch from one mode to the other?

3. Processes Fundamental abstraction of program execution memory
processor(s)
each processor abstraction is a thread
“execution context”
Unix, as do many operating systems, uses the notion of a process as its fundamental abstraction of program execution. Each program runs in a separate process. Processes are protected from one another in the sense that the actions of one process cannot directly harm others. The abstraction comprises the memory of a program (known as its address space—the collection of locations that can be referenced by the process), the execution agents (processor abstractions), and other information, known collectively as the execution context, representing such things as the files the process is currently accessing, how it responds to exceptions, to external stimuli, etc.
The processor abstraction is often called a thread. In “traditional” Unix programs, processes have only one thread, so we’ll use the word process to include the single thread running inside of it. Later in this course, when we cover multithreaded programming, we’ll be more careful and use the word thread when we are discussing the processor abstraction.

4. Process Concept
Process: an instance of a program, running with limited rights
Process control block: the data structure the OS uses to keep track of a process
Two parts to a process:
Thread: a sequence of instructions within a process
Potentially many threads per process (for now 1:1)
Thread aka lightweight process
Address space: set of rights of a process
Memory that the process can access
Other permissions the process has (e.g., which procedure calls it can make, what files it can access)

5. A Program
const int nprimes = 100; int prime[nprimes]; int main() { int i; int current = 2; prime[0] = current; for (i=1; i<nprimes; i++) { int j; NewCandidate: current++; for (j=0; prime[j]*prime[j] <= current; j++) { if (current % prime[j] == 0) goto NewCandidate; } prime[i] = current; return(0);

6. The Unix Address Space stack dynamic bss data text
A Unix process’s address space appears to be three regions of memory: a read-only text region (containing executable code); a read-write region consisting of initialized data (simply called data), uninitialized data (BSS—a directive from an ancient assembler (for the IBM 704 series of computers), standing for Block Started by Symbol and used to reserve space for uninitialized storage), and a dynamic area; and a second read-write region containing the process’s user stack (a standard Unix process contains only one thread of control).
The first area of read-write storage is often collectively called the data region. Its dynamic portion grows in response to sbrk system calls. Most programmers do not use this system call directly, but instead use the malloc and free library routines, which manage the dynamic area and allocate memory when needed by in turn executing sbrk system calls.
The stack region grows implicitly: whenever an attempt is made to reference beyond the current end of stack, the stack is implicitly grown to the new reference. (There are system-wide and per-process limits on the maximum data and stack sizes of processes.)

7. Typical Process Layout
Libraries provide the glue between user processes and the OS
libc linked in with all C programs
Provides printf, malloc, and a whole slew of other routines necessary for programs
Activation Records
Stack
Heap
OBJECT1
OBJECT2
HELLO WORLD
GO BIG RED CS!
Data
printf(char * fmt, …) {
create the string to be printed
SYSCALL 80 }
malloc() { … }
strcmp() { … }
Library
Text
main() {
printf (“HELLO WORLD”);
printf(“GO BIG RED CS”); !
Program

8. Full System Layout
The OS is omnipresent and steps in where necessary to aid application execution
Typically resides in high memory
When an application needs to perform a privileged operation, it needs to invoke the OS
USER OBJECT1
OBJECT2
OS Stack
OS Heap
OS Data
LINUX
syscall_entry_point() { … }
OS Text
Kernel Activation Records
OBJECT1
OBJECT2
Stack
Heap
Data
HELLO WORLD
GO BIG RED CS!
printf(char * fmt, …) {
main() { … }
Program
Library
Activation Records

9. Process Concept
OK, so you compile your program into an executable image with instructions and data.
What’s to keep the program from overwriting the OS kernel? Or some other program running at the same time?
What’s to keep it from overwriting the disk? From reading someone else’s files that are stored on disk?

10. Multiple Processes other stuff kernel stack other stuff kernel stack
kernel text
Each process has its own user address space, but there’s a single kernel address space. It contains context information for each user process, including the stacks used by each process when executing system calls.

11. Memory Protection

12. Memory Protection

13. Towards Virtual Addresses
Problems with base and bounds?
Expandable heap?
Expandable stack?
Memory sharing between processes?
Non-relative addresses – hard to move memory around
Memory fragmentation

14. Virtual Addresses Translation done in hardware, using a table
Table set up by operating system kernel
On every instruction!

15. Privileged Instructions

16. Privileged instructions
Examples?
What should happen if a user program attempts to execute a privileged instruction?
Change mode bit in EFLAGs register!
Change which memory locations a user program can access
Send commands to I/O devices
Read data from/write data to I/O devices
Jump into kernel code …

17. Thought Experiment
How can we implement execution with limited privilege?
Execute each program instruction in a simulator
If the instruction is permitted, do the instruction
Otherwise, stop the process
Basic model in Javascript, …
How do we go faster?
Run the unprivileged code directly on the CPU?
Upsides? Downsides to this approach? Essentially what you do in Javascript in a browser – simulate the execution of the script, one line at a time.

18. Privilege Levels
Some processor functionality cannot be made accessible to untrusted user applications
e.g. HALT, Read from disk, set clock, reset devices, manipulate device settings, …
Need to have a designated mediator between untrusted/untrusting applications
The operating system (OS)
Need to delineate between untrusted applications and OS code
Use a “privilege mode” bit in the processor
0 = Untrusted = user, 1 = Trusted = OS

19. Privilege Mode
Privilege mode bit indicates if the current program can perform privileged operations
On system startup, privilege mode is set to 1, and the processor jumps to a well-known address
The operating system (OS) boot code resides at this address
The OS sets up the devices, initializes the MMU, loads applications, and resets the privilege bit before invoking the application
Applications must transfer control back to OS for privileged operations

20. Challenge: Protection
How do we execute code with restricted privileges?
Either because the code is buggy or if it might be malicious
Some examples:
A script running in a web browser
A program you just downloaded off the Internet
A program you just wrote that you haven’t tested yet
Not just about OS’es; not just bugs

21. Hardware Support: Dual-Mode Operation
Kernel mode
Execution with the full privileges of the hardware
Read/write to any memory, access any I/O device, read/write any disk sector, send/read any packet
User mode
Limited privileges
Only those granted by the operating system kernel
On the x86, mode stored in EFLAGS register
Obviously, you need the part that has full rights to be really reliable!

22. A Model of a CPU

23. A CPU with Dual-Mode Operation

24. Hardware Support: Dual-Mode Operation
Privileged instructions
Available to kernel
Not available to user code
Limits on memory accesses
To prevent user code from overwriting the kernel
Timer
To regain control from a user program in a loop
Safe way to switch from user mode to kernel mode, and vice versa

25. Atomic Instructions
Hardware needs to provide special instructions to enable concurrent programs to operate correctly

26. Virtual Address Layout
Plus shared code segments, dynamically linked libraries, memory mapped files, …

27. Example: Corrected (What Does this Do?)
int staticVar = 0; // a static variable main() { int localVar = 0; // a procedure local variable staticVar += 1; localVar += 1; sleep(10); // sleep causes the program to wait for x seconds printf ("static address: %x, value: %d\n", &staticVar, staticVar); printf ("procedure local address: %x, value: %d\n", &localVar, localVar); } Produces: static address: 5328, value: 1 procedure local address: ffffffe2, value: 1
Because of stack address munging on modern systems (to prevent viruses), this won’t actually produce the same output when run repeatedly

28. Switch between hardware and kernel
Hardware Timer
Switch between hardware and kernel

29. Hardware Timer
Hardware device that periodically interrupts the processor
Returns control to the kernel timer interrupt handler
Interrupt frequency set by the kernel
Not by user code!
Interrupts can be temporarily deferred
Crucial for implementing mutual exclusion

30. Question
For a “Hello world” program, the kernel must copy the string from the user program memory into the screen memory. Why must the screen’s buffer memory be protected?

31. Question
Suppose we had a perfect object-oriented language and compiler, so that only an object’s methods could access the internal data inside an object. If the operating system only ran programs written in that language, would it still need hardware memory address protection?

33. Context switch between user-mode and kernel

34. Mode Switch From user-mode to kernel Interrupts Exceptions
Triggered by timer and I/O devices
Exceptions
Triggered by unexpected program behavior
Or malicious behavior!
System calls (aka protected procedure call)
Request by program for kernel to do some operation on its behalf
Only limited # of very carefully coded entry points

35. Mode Switch From kernel-mode to user New process/new thread start
Jump to first instruction in program/thread
Return from interrupt, exception, system call
Resume suspended execution
Process/thread context switch
Resume some other process
User-level upcall
Asynchronous notification to user program

36. Context switch
Interrupts

37. Basic Computer Organization
Memory
CPU ?

38. Keyboard Let’s build a keyboard
Lots of mechanical switches
Need to convert to a compact form (binary)
We’ll use a special mechanical switch that, when pressed, connects two wires simultaneously

39. Keyboard When a key is pressed, a 7-bit key identifier is computed +
3-bit encoder
(4 to 3)
4-bit encoder
(16 to 4)
not all 16 wires are shown

40. Keyboard A latch can store the keystroke indefinitely + Latch
3-bit encoder
(4 to 3)
4-bit encoder
(16 to 4)
not all 16 wires are shown
Latch
A latch can store the keystroke indefinitely

41. Keyboard
CPU +
3-bit encoder
(4 to 3)
4-bit encoder
(16 to 4)
not all 16 wires are shown
Latch
The keyboard can then appear to the CPU as if it is a special memory address

42. Device Interfacing Techniques
Memory-mapped I/O
Device communication goes over the memory bus
Reads/Writes to special addresses are converted into I/O operations by dedicated device hardware
Each device appears as if it is part of the memory address space
Programmed I/O
CPU has dedicated, special instructions
CPU has additional input/output wires (I/O bus)
Instruction specifies device and operation
Memory-mapped I/O is the predominant device interfacing technique in use

43. Polling vs. Interrupts
One design is the CPU constantly needs to read the keyboard latch memory location to see if a key is pressed
Called polling
Inefficient
An alternative is to add extra circuitry so the keyboard can alert the CPU when there is a keypress
Called interrupt driven I/O
Interrupt driven I/O enables the CPU and devices to perform tasks concurrently, increasing throughput
Only needs a tiny bit of circuitry and a few extra wires to implement the “alert” operation

44. Interrupt Driven I/O CPU Memory
Interrupt Controller
intr
CPU
dev id
An interrupt controller mediates between competing devices
Raises an interrupt flag to get the CPU’s attention
Identifies the interrupting device
Can disable (aka mask) interrupts if the CPU so desires

45. Interrupt Management Interrupt controllers manage interrupts
Maskable interrupts: can be turned off by the CPU for critical processing
Nonmaskable interrupts: signifies serious errors (e.g. unrecoverable memory error, power out warning, etc)
Interrupts contain a descriptor of the interrupting device
A priority selector circuit examines all interrupting devices, reports highest level to the CPU
Interrupt controller implements interrupt priorities
Can optionally remap priority levels

46. How do we take interrupts safely?
Interrupt vector
Limited number of entry points into kernel
Kernel interrupt stack
Handler works regardless of state of user code
Interrupt masking
Handler is non-blocking
Atomic transfer of control
Single instruction to change:
Program counter
Stack pointer
Memory protection
Kernel/user mode
Transparent restartable execution
User program does not know interrupt occurred

47. Interrupt Vector
Table set up by OS kernel; pointers to code to run on different events
Note: by “processor register” I do not mean %eax. Rather – these are special purpose registers.

48. Interrupt Masking Interrupt handler runs with interrupts off
Reenabled when interrupt completes
OS kernel can also turn interrupts off
Eg., when determining the next process/thread to run
If defer interrupts too long, can drop I/O events

49. Interrupt Handlers Non-blocking, run to completion
Minimum necessary to allow device to take next interrupt
Any waiting must be limited duration
Wake up other threads to do any real work
Pintos: semaphore_up
Rest of device driver runs as a kernel thread
Queues work for interrupt handler
(Sometimes) wait for interrupt to occur

50. Atomic Mode Transfer Context Switch
On interrupt (x86)
Save current stack pointer
Save current program counter
Save current processor status word (condition codes)
Switch to kernel stack; put SP, PC, PSW on stack
Switch to kernel mode
Vector through interrupt table
Interrupt handler saves registers it might clobber

51. Before

52. During

53. After

54. At end of handler Handler restores saved registers
Atomically return to interrupted process/thread
Restore program counter
Restore program stack
Restore processor status word/condition codes
Switch to user mode

55. Exceptional Situations
System calls are control transfers to the OS, performed under the control of the user application
Sometimes, need to transfer control to the OS at a time when the user program least expects it
Division by zero,
Alert from the power supply that electricity is about to go out,
Alert from the network device that a packet just arrived,
Clock notifying the processor that the clock just ticked,
Some of these causes for interruption of execution have nothing to do with the user application
Need a (slightly) different mechanism, that allows resuming the user application

56. Interrupts & Exceptions
On an interrupt or exception
Switches the stack pointer to the kernel stack
Saves the old (user) SP value
Saves the old (user) Program Counter value
Saves the old privilege mode
Saves cause of the interrupt/exception
Sets the new privilege mode to 1
Sets the new PC to the kernel interrupt/exception handler
Kernel interrupt/exception handler handles the event
Saves all registers
Examines the cause
Performs operation required
Restores all registers
Performs a “return from interrupt” instruction, which restores the privilege mode, SP and PC

57. Before

58. After

59. Interrupt Stack Per-processor, located in kernel (not user) memory
Usually a thread has both: kernel and user stack
Why can’t interrupt handler run on the stack of the interrupted user process?

60. Interrupt Stack

61. Context switch
System Calls

62. System Calls
A system call is a controlled transfer of execution from unprivileged code to the OS
A potential alternative is to make OS code read-only, and allow applications to just jump to the desired system call routine. Why is this a bad idea?
A SYSCALL instruction transfers control to a system call handler at a fixed address

63. System Calls Kernel portion of address space trap into kernel
kernel text
other stuff
kernel stack
Kernel portion of address space
trap into kernel
User portion of address space
write(fd, buf, len)

64. System Calls Sole interface between user and kernel
Implemented as library routines that execute trap instructions to enter kernel
Errors indicated by returns of –1; error code is in errno
if (write(fd, buffer, bufsize) == –1) {
// error!
printf("error %d\n", errno);
// see perror }
System calls, such as fork, execv, read, write, etc., are the only means for application programs to communicate directly with the kernel: they form an API (application program interface) to the kernel. When a program calls such a routine, it is actually placing a call to a subroutine in a system library. The body of this subroutine contains a hardware-specific trap instruction which transfers control and some parameters to the kernel. On return to this library return, the kernel provides an indication of whether or not there was an error and what the error was. The error indication is passed back to the original caller via the functional return value of the library routine. If there was an error, a positive-integer code identifying it is stored in the global variable errno. Rather than simply print this code out, as shown in the slide, one might instead print out an informative error message. This can be done via the perror routine.

65. Sample System Calls Print character to screen
Needs to multiplex the shared screen resource between multiple applications
Send a packet on the network
Needs to manipulate the internals of a device whose hardware interface is unsafe
Allocate a page
Needs to update page tables & MMU

66. Syscall vs. Interrupt
The differences lie in how they are initiated, and how much state needs to be saved and restored
Syscall requires much less state saving
Caller-save registers are already saved by the application
Interrupts typically require saving and restoring the full state of the processor
Because the application got struck by a lightning bolt without anticipating the control transfer

67. System Calls

68. Kernel System Call Handler
Locate arguments
In registers or on user(!) stack
Copy arguments
From user memory into kernel memory
Protect kernel from malicious code evading checks
Validate arguments
Protect kernel from errors in user code
Copy results back
into user memory

69. SYSCALL instruction
SYSCALL instruction does an atomic jump to a controlled location
Switches the sp to the kernel stack
Saves the old (user) SP value
Saves the old (user) PC value (= return address)
Saves the old privilege mode
Sets the new privilege mode to 1
Sets the new PC to the kernel syscall handler
Kernel system call handler carries out the desired system call
Saves callee-save registers
Examines the syscall number
Checks arguments for sanity
Performs operation
Stores result in v0
Restores callee-save registers
Performs a “return from syscall” instruction, which restores the privilege mode, SP and PC

70. Web Server Example

71. System Boot

72. System Boot
Operating system must be made available to hardware so hardware can start it
Small piece of code – bootstrap loader, locates the kernel, loads it into memory, and starts it
Sometimes two-step process where boot block at fixed location loads bootstrap loader
When power initialized on system, execution starts at a fixed memory location
Firmware used to hold initial boot code

73. Booting

74. Virtual Machines

75. Virtual Machines
A virtual machine takes the layered approach to its logical conclusion. It treats hardware and the operating system kernel as though they were all hardware
A virtual machine provides an interface identical to the underlying bare hardware
The operating system host creates the illusion that a process has its own processor and (virtual memory)
Each guest provided with a (virtual) copy of underlying computer

76. Virtual Machine

77. Virtual Machines (Cont)
(a) Nonvirtual machine (b) virtual machine
Non-virtual Machine
Virtual Machine

78. User-Level Virtual Machine
How does VM Player work?
Runs as a user-level application
How does it catch privileged instructions, interrupts, device I/O, …
Installs kernel driver, transparent to host kernel
Requires administrator privileges!
Modifies interrupt table to redirect to kernel VM code
If interrupt is for VM, upcall
If interrupt is for another process, reinstalls interrupt table and resumes kernel

79. Context switch
System Upcalls

80. Upcall: User-level interrupt
AKA UNIX signal
Notify user process of event that needs to be handled right away
Time-slice for user-level thread manager
Interrupt delivery for VM player
Direct analogue of kernel interrupts
Signal handlers – fixed entry points
Separate signal stack
Automatic save/restore registers – transparent resume
Signal masking: signals disabled while in signal handler

81. Upcall: Before

82. Upcall: After

83. Terminology Trap Syscall Exception Interrupt
Any kind of a control transfer to the OS
Syscall
Synchronous, program-initiated control transfer from user to the OS to obtain service from the OS
e.g. SYSCALL
Exception
Asynchronous, program-initiated control transfer from user to the OS in response to an exceptional event
e.g. Divide by zero, segmentation fault
Interrupt
Asynchronous, device-initiated control transfer from user to the OS
e.g. Clock tick, network packet