System Calls, Interrupts and Exceptions

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.

Operating System Structure www.cs rutgers.edu/~pxk

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.

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

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

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!

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.

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.

Context switch between user-mode and kernel

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

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

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.

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.

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.

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.

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.

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

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

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

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

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

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

Before

After

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?

Interrupt Stack

Context switch System Calls

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.

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.

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.

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)

System Calls (1) Figure 1-17. 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.

System Calls (2) Figure 1-18. 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.

System Calls (3) Figure 1-18. 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.

System Calls (4) Figure 1-18. 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.

System Calls (5) Figure 1-18. 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.

System Calls for Process Management Figure 1-19. 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.

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

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

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

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.

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

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

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

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.

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

Virtual Machines Rediscovered Figure 1-29. (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.

Virtual Machines

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

Virtual Machine

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

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

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