1. System Calls, Interrupts and Exceptions

2. What is an operating system
The first program
A program that lets you run other programs
A program that provides controlled access to resources:
CPU
Memory
Display, keyboard, mouse
Persistent storage
Network
Tanenbaum & Bo, Modern Operating Systems:4th ed., (c) 2013 Prentice-Hall, Inc. All rights reserved.

3. Operating System Structure
rutgers.edu/~pxk

4. kernel
Core component of the operating system: the central program that manages resources and scheduling
Controls execution of programs
Schedules
Allocates memory
Allows programs to controlled access to devices
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.

5. 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

6. 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, loads applications, and resets the privilege bit before invoking the application
Applications must transfer control back to OS for privileged operations

7. 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
Obviously, you need the part that has full rights to be really reliable!

8. Am I in user mode?
Processor instructions available only to privileged programs (like OS)
Status register usually contains information about privilege
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.

9. Execution: User Mode vs Kernel Mode
• Kernel mode = privileged, system, supervisor
mode
Access restricted regions of memory
Modify the memory management unit
Set timers
Define interrupt vectors
Halt the processor
Tanenbaum & Bo, Modern Operating Systems:4th ed., (c) 2013 Prentice-Hall, Inc. All rights reserved.

10. Context switch between user-mode and kernel

11. 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

12. 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

13. How do I get to kernel mode
Interrupt Vector Table
Configured by kernel at boot time
Depending on architecture
Code entry points
Control jumps to an entry in the table based on trap number
Table will contain a set of JMP instructions to different Handlers in the kernel
List of addresses
Each entry contains a structure that defines the target address & privilege level
–Table will contain a set of addresses for different handlers in the kernel
Tanenbaum & Bo, Modern Operating Systems:4th ed., (c) 2013 Prentice-Hall, Inc. All rights reserved.

14. 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.

15. Flow of control
Each interrupt has a number associated that is an index into the interrupt vector table
Table also has address of the code to handle that specific interrupt
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.

16. Flow of control Save processors registers
Set up for execution in the kernel
Choose a place the for the kernel to start executing
Retrieve information about the event
Transfer the control back to the user
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.

17. Flow of Control User-programmed interrupt instruction
The instruction forces the program to jump to a well-known address based on the number of the interrupt.
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.

18. 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

19. 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

20. 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

21. 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

22. 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

23. 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

24. Before

25. After

26. 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?

27. Interrupt Stack

28. Context switch
System Calls

29. 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.

30. System Calls: Interacting with the OS
A system call is a way for a user program to request services from the operating system
The operating system remains in control of devices
Enforces policies
Use trap mechanism to switch to the kernel
User ↔ Kernel mode switch: Mode switch
Note: most architectures support an optimized trap for system calls
Tanenbaum & Bo, Modern Operating Systems:4th ed., (c) 2013 Prentice-Hall, Inc. All rights reserved.

31. System Calls: Interacting with the OS
Use trap mechanism to switch to the kernel
Pass a number that represents the OS service (e.g., read)
System call number; usually set in a register
A system call does the following:
Set the system call number
Save parameters
Issue the trap (jump to kernel mode)
OS gets control
Saves registers, does the requested work
Return from exception (back to user mode)
Retrieve results and return them to the calling function
System call interfaces are encapsulated as library functions
Tanenbaum & Bo, Modern Operating Systems:4th ed., (c) 2013 Prentice-Hall, Inc. All rights reserved.

32. 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)

33. System Calls (1)
Figure The 11 steps in making the system call read(fd, buffer, nbytes).
Tanenbaum & Bo, Modern Operating Systems:4th ed., (c) 2013 Prentice-Hall, Inc. All rights reserved.

34. System Calls (2)
Figure Some of the major POSIX system calls. The return code s is −1 if an error has occurred. The return codes are as follows: pid is a process id, fd is a file descriptor, n is a byte count, position is an offset within the file, and seconds is the elapsed time.
Tanenbaum & Bo, Modern Operating Systems:4th ed., (c) 2013 Prentice-Hall, Inc. All rights reserved.

35. System Calls (3)
Figure Some of the major POSIX system calls. The return code s is −1 if an error has occurred. The return codes are as follows: pid is a process id, fd is a file descriptor, n is a byte count, position is an offset within the file, and seconds is the elapsed time.
Tanenbaum & Bo, Modern Operating Systems:4th ed., (c) 2013 Prentice-Hall, Inc. All rights reserved.

36. System Calls (4)
Figure Some of the major POSIX system calls. The return code s is −1 if an error has occurred. The return codes are as follows: pid is a process id, fd is a file descriptor, n is a byte count, position is an offset within the file, and seconds is the elapsed time.
Tanenbaum & Bo, Modern Operating Systems:4th ed., (c) 2013 Prentice-Hall, Inc. All rights reserved.

37. System Calls (5)
Figure Some of the major POSIX system calls. The return code s is −1 if an error has occurred. The return codes are as follows: pid is a process id, fd is a file descriptor, n is a byte count, position is an offset within the file, and seconds is the elapsed time.
Tanenbaum & Bo, Modern Operating Systems:4th ed., (c) 2013 Prentice-Hall, Inc. All rights reserved.

38. System Calls for Process Management
Figure A stripped-down shell. Throughout this book, TRUE is assumed to be defined as 1.
Tanenbaum & Bo, Modern Operating Systems:4th ed., (c) 2013 Prentice-Hall, Inc. All rights reserved.

39. The Windows Win32 API (1)
Figure The Win32 API calls that roughly correspond to the UNIX calls of Fig
Tanenbaum & Bo, Modern Operating Systems:4th ed., (c) 2013 Prentice-Hall, Inc. All rights reserved.

40. The Windows Win32 API (2)
Figure The Win32 API calls that roughly correspond to the UNIX calls of Fig
Tanenbaum & Bo, Modern Operating Systems:4th ed., (c) 2013 Prentice-Hall, Inc. All rights reserved.

41. Operating System Structure
Tanenbaum & Bo, Modern Operating Systems:4th ed., (c) 2013 Prentice-Hall, Inc. All rights reserved.

42. Monolithic Systems (1) Basic structure of OS
A main program that invokes the requested service procedure.
A set of service procedures that carry out the system calls.
A set of utility procedures that help the service procedures.
Tanenbaum & Bo, Modern Operating Systems:4th ed., (c) 2013 Prentice-Hall, Inc. All rights reserved.

43. Figure 1-24. A simple structuring model for a monolithic system.
Monolithic Systems (2)
Figure A simple structuring model for a monolithic system.
Tanenbaum & Bo, Modern Operating Systems:4th ed., (c) 2013 Prentice-Hall, Inc. All rights reserved.

44. Figure 1-25. Structure of the THE operating system.
Layered Systems
Figure Structure of the THE operating system.
Tanenbaum & Bo, Modern Operating Systems:4th ed., (c) 2013 Prentice-Hall, Inc. All rights reserved.

45. Figure 1-26. Simplified structure of the
Microkernels
Figure Simplified structure of the
MINIX 3 system.
Tanenbaum & Bo, Modern Operating Systems:4th ed., (c) 2013 Prentice-Hall, Inc. All rights reserved.

46. Figure 1-27. The client-server model over a network.
Tanenbaum & Bo, Modern Operating Systems:4th ed., (c) 2013 Prentice-Hall, Inc. All rights reserved.

47. Figure 1-28. The structure of VM/370 with CMS.
Virtual Machines
Figure The structure of VM/370 with CMS.
Tanenbaum & Bo, Modern Operating Systems:4th ed., (c) 2013 Prentice-Hall, Inc. All rights reserved.

48. Virtual Machines Rediscovered
Figure (a) A type 1 hypervisor. (b) A pure type 2 hypervisor. (c) A practical type 2 hypervisor.
Tanenbaum & Bo, Modern Operating Systems:4th ed., (c) 2013 Prentice-Hall, Inc. All rights reserved.

49. Virtual Machines

50. 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

51. Virtual Machine

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

53. 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

54. End
Chapter 1
Tanenbaum & Bo, Modern Operating Systems:4th ed., (c) 2013 Prentice-Hall, Inc. All rights reserved.