W 4118 Operating Systems Interrupt and System Call

W 4118 Operating Systems Interrupt and System Call Instructor: Junfeng Yang

Logistics q Room change: 633 Mudd q Homework 1 out, due Thu 2/5 at 4: 09 pm EST

Last lecture q What is OS? Stuff between § § q What functionality in OS? § q App view: hw abstraction layer Sys view: resource mgr Users + hardware functionality Concepts § § User App OS HW Batching: work on group of jobs, so can optimize Spooling: overlap I/O with compute • OS: buffering, DMA, interrupt § Multiprogramming: keep N jobs in mem, OS chooses which to run • OS: job scheduling, mem mgmt § Timesharing: fast switch view of dedicated machine • OS: more complex scheduling, mem mgmt, concurrency control, synchronization

Today q OS: event-driven § § q Interrupt § § § q Device events: interrupt Application events: system call Background How interrupt works Some tricky points System call User App OS HW

Computer Organization q Computer-system operation § One or more CPUs, device controllers connect through common bus providing access to shared memory

CPU q CPU runs instructions: § § § q Needs work space: registers § § q E. g. x 86 has 8 general purpose registers: EAX, EBX, ECX, EDX, ESI, EDI, EBP, ESP Very fast, very few Needs more work space: memory § § § q while (fetch next instruction){ run instruction } CPU has address line, data line Sends out address on address line Data comes back on data line, or data is written to data line Instructions in memory too! § § IP: instruction pointer (or Program Counter) Increment after running each instruction

CPU’s ‘fetch-execute’ cycle User Program ld Fetch instruction at IP add IP st mul Decode the fetched instruction ld sub Execute the decoded instruction bne add jmp … Advance IP to next instruction

How to bootstrap this cycle? q q Where to find the first instruction? The boot process 1. When CPU powers up, IP always points to fixed memory address (0 xfffffff 0) 2. This memory address maps to ROM with BIOS 3. BIOS executes, initializes your computer 4. BIOS loads boot loader from first sector of disk (MBR) into RAM, then jump 5. Boot loader loads your kernel § Can have two-level boot loader, or no boot loader

How do devices gain CPU’s attention?

How do devices gain CPU’s attention? q q I/O devices and the CPU can execute concurrently Device controller: in charge of a device type § § § q Each device controller has a local buffer CPU moves data b/w main memory controller buffers (spooling) I/O: b/w controller buffer and device Device controller informs CPU that it has finished its operation by causing an interrupt § Controller buffer small, want better interactivity Want CPU to respond fast

CPU’s ‘fetch-execute’ cycle with interrupt User Program ld add Fetch instruction at IP st IP mul Save context Decode the fetched instruction ld sub bne Execute the decoded instruction add jmp … Get INTR # Lookup ISR Advance IP to next instruction Execute ISR IRQ? no yes IRET

Interrupt Hardware (legacy systems) IRQs Ethernet Slave PIC (8259) SCSI Disk Real-Time Clock Keyboard Controller q q q Master PIC (8259) INTR x 86 CPU intr # Programmable Interval-Timer I/O devices have (unique or shared) Interrupt Request Lines (IRQs) IRQs are mapped by special hardware to interrupt numbers, and passed to the CPU This hardware is called a Programmable Interrupt Controller (PIC)

The `Interrupt Controller’ q q q Responsible for telling the CPU when a specific external device wishes to ‘interrupt’ § Needs to tell the CPU which one among several devices is the one needing service PIC translates IRQ to interrupt number § Raises interrupt to CPU § Interrupt # available in register § Waits for ack from CPU Interrupts can have varying priorities § PIC also needs to prioritize multiple requests Possible to “mask” (disable) interrupts at PIC or CPU Early systems cascaded two 8 input chips (8259 A)

Example: Interrupts on 80386 q q 80386 core has one interrupt line, one interrupt acknowledge line Interrupt sequence: § § § Interrupt controller raises INT line 80386 core pulses INTA line low, allowing INT to go low 80386 core pulses INTA line low again, signaling controller to put interrupt number on data bus

CPU’s ‘fetch-execute’ cycle with interrupt User Program ld add Fetch instruction at IP st IP mul Save context Decode the fetched instruction ld sub bne Execute the decoded instruction add jmp … Get INTR ID Lookup ISR Advance IP to next instruction Execute ISR IRQ? no yes IRET

Interrupt Descriptor Table q q The ‘entry-point’ to the interrupt-handler is located via the Interrupt Descriptor Table (IDT) Interrupt Service Routine = IDT[Interrupt number] § Also called interrupt handler q IDT is in memory, initialized by OS at boot q How to locate base of IDT? § CPU has a register, idtr, pointing to IDT, initialized by OS via the LIDT instruction at boot

Putting It All Together Memory Bus intr # IRQs PIC idtr INTR CPU 0 IDT intr # ISR Mask points 255

Some tricky points q Must be able to resume user program after interrupt, so need to save instruction pointer and other registers § q To preserve IRQ order on the same line, must disable incoming interrupts (all or same line) § q Some done in hardware, some in handler Done in handler Thus, handler must run for a very short time § § Preempts what CPU was doing, which may be important Don’t want to interrupt user program for long Don’t want to disable interrupt for long (otherwise, may lose interrupts) Lead to some complex implementations. We’ll see in Linux

Interrupt v. s. Polling q Instead for device to interrupt CPU, CPU can poll the status of device § § q Intr: “I want to see a movie. ” Poll: While(1) {“Do you want to see a movie? ”} Good or bad? § § For mostly-idle device? For busy device?

Same Interrupt mechanism used for other unusual control transfers q q We’ve seen Interrupts: raised externally by device Traps (or Exceptions): raised internally by CPU § § q 0: divide-overflow fault 3: breakpoint 6: Undefined Opcode 13: General Protection Exception System call can be implemented this way too § Linux system call: INT 0 x 80

System calls q Programming interface to OS services q Next: § § § Protection System calls and application programming interface (API) How to implement system calls

The need for protection q For reliability: buggy or malicious user program § § § q For security: malicious user program § § q Exceptions (division by 0, buffer overrun, dereference NULL, …) Resource hogs (infinite loops, exhaust memory …) Despite these, OS cannot crash, must serve other processes and users Read/write OS or other process’s data without permission OS must check, and check code cannot be tampered Must distinguish trusted (OS) and untrusted (user program)

Dual-mode operation q Allows OS to protect itself and other system components § § User mode and kernel mode Mode bit provided by hardware • Provides ability to distinguish when system is running user code or kernel code • Some instructions designated as privileged, only executable in kernel mode • If executed in user mode, exception • X 86 actually has 4 modes, but only 2 used q To perform privileged operations, must transit into OS through well defined interfaces § § System calls Interrupt handlers too

Example transition: system call q Call: changes mode to kernel § int 0 x 80 OS validates system call q Return: resets it to user q § iret

Example transition: timer interrupt q Timer to prevent infinite loop / process hogging resources § § Set interrupt after specific period Set up before scheduling process to regain control or terminate program that exceeds allotted time When interrupt occurs, switch from current process to another (slightly simplified)

System Calls and API q Mostly accessed by programs via a high-level Application Program Interface (API) rather than direct system call use § q Example API: Win 32 API, POSIX API Why use APIs rather than system calls? § Give OS some flexibility • Can have non-standard or not-so-easy-to-use system call interface. Fix things up in libs (usually easier than fix in kernel) (Note that the system-call names used throughout this text are generic)

System Call Implementation q Typically, a number associated with each system call § § q q System-call interface maintains a table indexed according to these numbers Similar to interrupt, but dispatched in software The system call interface invokes intended system call in OS kernel and returns status of the system call and any return values Apps only need to know API, not system call interface

API – System Call – OS Relationship { printf(“hello world!n”); } libc User mode %eax = sys_write; int 0 x 80 system_call() { fn = syscalls[%eax] kernel mode 0 x 80 IDT } syscalls table sys_write(…) { // do real work }

System Call Parameter Passing q Often, more information is required than simply identity of desired system call § q Exact type and amount of information vary according to OS and call Three general methods used to pass parameters to the OS § Simplest: pass the parameters in registers • In some cases, may be more parameters than registers § Parameters stored in a block, or table, in memory, and address of block passed as a parameter in a register • This approach taken by Linux and Solaris § § Parameters placed, or pushed, onto the stack by the program and popped off the stack by the operating system Block and stack methods do not limit the number or length of parameters being passed

Parameter Passing via Table

Types of System Calls q Process control q File management q Device management q Information maintenance q Communications

Case study: the shell (simplified) q Shell: interactive command line interface § § User types command, shell executes Thus, need to create process to run command while (1) { write (1, "$ “, 2); parse_cmd (command, args); // parse user input switch(pid = fork ()) { case -1: perror (“fork”); break; case 0: // child execv (command, args, 0); break; default: // parent wait (0); break; // wait for child to terminate } }

Case study: the shell (cont. ) q q System calls for files: open, read, write, close Identify opened file with file descriptors, numbered starting from 0 § Avoid repeated path resolution OS knows when file is closed can reclaim resource Avoid race: same name may map to different file § fd 0: input (e. g. keyboard) § fd 1: output (e. g. screen) § Fd 2: error output (e. g. screen) § § q q q Naming conventions • parse_cmd: read(0, bufsize) • Write(1, “hellon”, strlen(“hellon”); • Often use libc function (printf, fprintf, etc) On fork, child copies fd On exec, retains fd (except those specifically marked as close-on-exec: fcntl(fd, F_SETFD, FD_CLOEXEC))

Case study: the shell (cont. ) q I/O redirection: “ls > tmp 1” q How does the shell implement I/O redirection fd = open (“tmp 1”, …); // error checking omitted if (fd != 1) { dup 2 (fd, 1); // 1 is a copy of fd, thus points to file tmp 1 close (fd); }

q System calls and API q Q: what system calls and APIs to provide? Q: how to implement? q Next: OS design and implementation q

OS design and implementation q q q Design and Implementation of OS not “solvable”, but some approaches have proven successful Internal structure of different Operating Systems can vary widely Start by defining goals and specifications Affected by choice of hardware, type of system User goals and System goals § § User goals – operating system should be convenient to use, easy to learn, reliable, safe, and fast System goals – operating system should be easy to design, implement, and maintain, as well as flexible, reliable, error-free, and efficient

Operating System Design and Implementation (Cont. ) q Important principle to separate Policy: What will be done? Mechanism: How to do it? q Mechanisms determine how to do something, policies decide what will be done § The separation of policy from mechanism is a very important principle, it allows maximum flexibility if policy decisions are to be changed later

Simple Structure q MS-DOS – written to provide the most functionality in the least space § § q q Not divided into modules Although MS-DOS has some structure, its interfaces and levels of functionality are not well separated No protection user program crashes entire machine Hardware reason: 8088 has no protection

MS-DOS Layer Structure

Unix q UNIX – limited by hardware functionality, the original UNIX operating system had limited structuring. The UNIX OS consists of two separable parts § § Systems programs The kernel • Consists of everything below the system-call interface and above the physical hardware • Provides the file system, CPU scheduling, memory management, and other operating-system functions; a large number of functions for one level

UNIX System Structure

Layered Approach q The operating system is divided into a number of layers (levels), each built on top of lower layers. The bottom layer (layer 0), is the hardware; the highest (layer N) is the user interface. q With modularity, layers are selected such that each uses functions (operations) and services of only lowerlevel layers

Layered Operating System

Microkernel System Structure q q q Moves as much from the kernel into “user” space Communication takes place between user modules using message passing Claimed benefits: § § q Easier to extend a microkernel Easier to port the operating system to new architectures More reliable (less code is running in kernel mode) More secure Detriments: § Performance overhead of user space to kernel space communication

Mac OS X Structure

Modules q Most modern operating systems implement kernel modules § Uses object-oriented approach • Function pointers in Linux: OOP with C § § § Each core component is separate Each talks to the others over known interfaces Each is loadable as needed within the kernel q Overall, flexible similar to layers but with more

Solaris Modular Approach

Virtual Machines q q q 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 creates the illusion of multiple processes, each executing on its own processor with its own (virtual) memory

Virtual Machines (Cont. ) q The resources of the physical computer are shared to create the virtual machines § § § CPU scheduling can create the appearance that users have their own processor Spooling and a file system can provide virtual card readers and virtual line printers A normal user time-sharing terminal serves as the virtual machine operator’s console

Virtual Machines (Cont. ) Non-virtual Machine Virtual Machine

Virtual Machines (Cont. ) q q q The virtual-machine concept provides complete protection of system resources since each virtual machine is isolated from all other virtual machines. This isolation, however, permits no direct sharing of resources. A virtual-machine system is a perfect vehicle for operating-systems research and development. System development is done on the virtual machine, instead of on a physical machine and so does not disrupt normal system operation. The virtual machine concept is difficult to implement due to the effort required to provide an exact duplicate to the underlying machine

VMware Architecture

Next lecture q Interrupts and system calls in Linux