Architectural Support for Operating Systems

1. Architectural Support for Operating Systems

2. Announcements

3. Today’s material • I/O subsystem and device drivers • Interrupts and traps • Protection, system calls and operating mode • OS structure • What happens when you boot a computer?

4. Computer System Architecture Synchronizes memory access

5. I/O operations • I/O devices and the CPU can execute concurrently. • I/O is moving data between device & controller’s buffer • CPU moves data between controller’s buffer & main memory • Each device controller is in charge of certain device type. • May be more than one device per controller • SCSI can manage up to 7 devices • Each device controller has local buffer, special registers • A device driver for every device controller • Knows details of the controller • Presents a uniform interface to the rest of OS

6. Accessing I/O Devices • Memory Mapped I/O • I/O devices appear as regular memory to CPU • Regular loads/stores used for accessing device • This is more commonly used • Programmed I/O • Also called “channel” I/O • CPU has separate bus for I/O devices • Special instructions are required • Which is better?

7. Polling I/O • Each device controller typically has: • Data-in register (for host to receive input from device) • Data-out (for host to send output to device) • Status register (read by host to determine device state) • Control register (written by host to invoke command)

8. Polling I/O handshaking: • To write data to a device: • Host repeatedly reads busy bit in status register until clear • Host sets write bit in command register and writes output in data-out register • Host sets command-ready bit in control register • Controller notices command-ready bit, sets busy bit in status register • Controller reads command register, notices write bit: reads data-out register and performs I/O (magic) • Controller clears command-ready bit, clears the error bit (to indicate success) and clears the busy bit (to indicate it’s finished)

9. Polling I/O • What’s the problem? • CPU could spend most its time polling devices, while other jobs go undone. • But devices can’t be left to their own devices for too long • Limited buffer at device - could overflow if doesn’t get CPU service. • Modern operating systems uses Interrupts to solve this dilemma. • Interrupts: Notification from interface that device needs servicing • Hardware: sends trigger on bus • Software: uses a system call

10. Interrupts • CPU hardware has a interrupt-request line (a wire) it checks after processing each instruction. • On receiving signal Save processing state • Jump to interrupt handler routine at fixed address in memory • Interrupt handler: • Determine cause of interrupt. • Do required processing. • Restore state. • Execute return from interrupt instruction. • Device controller raises interrupt, CPU catches it, interrupt handler dispatches and clears it. • Modern OS needs more sophisticated mechanism: • Ability to defer interrupt • Efficient way to dispatch interrupt handler • Multilevel interrupts to to distinguish between high and low priority interrupts.

11. Modern interrupt handling • Use a specialized Interrupt Controller • CPUs typically have two interrupt request lines: • Maskable interrupts: Can be turned of by CPU before critical processing • Nonmaskable interrupts: signifies serious error (e.g. unrecoverable memory error) • Interrupts contain address pointing to interrupt vector • Interrupt vector contains addresses of specialized interrupt handlers. • If more devices than elements in interrupt vector; do interrupt chaining: • A list of interrupt handlers for a given address which must be traversed to determine the appropriate one. • Interrupt controller also implements interrupt priorities • Higher priority interrupts can pre-empt processing of lower priority ones

12. Even interrupts are sometimes to slow: • Device driver loads controller registers appropriately • Controller examines registers, executes I/O • Controller signals I/O completion to device driver • Using interrupts • High overhead for moving bulk data (i.e. disk I/O): • One interrupt per byte..

13. Direct Memory Access (DMA) • Transfer data directly between device and memory • No CPU intervention • Device controller transfers blocks of data • Interrupts when block transfer completed • As compared to when byte is completed • Very useful for high-speed I/O devices

14. Example I/O Memory Instructions and Data Instruction execution cycle Thread of execution cache Data movement CPU (*N) I/O Request Interrupt DMA Data Keyboard Device Driver and Keyboard Controller Disk Device Driver and Disk Controller Perform I/O Read Data

15. Interrupt Timeline

16. Traps and Exceptions • Software generated interrupt • Exception: user program acts silly • Caused by an error (div by 0, or memory access violation) • Just a performance optimization • Trap: user program requires OS service • Caused by system calls • Handled similar to hardware interrupts: • Stops executing the process • Calls handler subroutine • Restores state after servicing the trap

17. Why Protection? • Application programs could: • Start scribbling into memory • Get into infinite loops • Other users could be: • Gluttonous • Evil • Or just too numerous • Correct operation of system should be guaranteed  A protection mechanism

18. Preventing Runaway Programs • Also how to prevent against infinite loops • Set a timer to generate an interrupt in a given time • Before transferring to user, OS loads timer with time to interrupt • Operating system decrements counter until it reaches 0 • The program is then interrupted and OS regains control. • Ensures OS gets control of CPU • When erroneous programs get into infinite loop • Programs purposely continue to execute past time limit • Setting this timer value is a privileged operation • Can only be done by OS

19. Protecting Memory • Protect program from accessing other program’s data • Protect the OS from user programs • Simplest scheme is base and limit registers: • Virtual memory and segmentation are similar memory Prog A Base register Loaded by OS before starting program Prog B Limit register Prog C

20. Protected Instructions Also called privileged instructions. Some examples: • Direct user access to some hardware resources • Direct access to I/O devices like disks, printers, etc. • Instructions that manipulate memory management state • page table pointers, TLB load, etc. • Setting of special mode bits • Halt instruction Needed for: • Abstraction/ease of use and protection

21. Dual-Mode Operation • Allows OS to protect itself and other system components • User mode and kernel mode • OS runs in kernel mode, user programs in user mode • OS is god, the applications are peasants • Privileged instructions only executable in kernel mode • Mode bit provided by hardware • Can distinguish if system is running user code or kernel code • System call changes mode to kernel • Return from call using RTI resets it to user • How do user programs do something privileged?

22. Crossing Protection Boundaries • User calls OS procedure for “privileged” operations • Calling a kernel mode service from user mode program: • Using System Calls • System Calls switches execution to kernel mode User Mode Mode bit = 1 Resume process User process System Call Trap Mode bit = 0 Kernel Mode Mode bit = 0 Return Mode bit = 1 Save Caller’s state Execute system call Restore state

23. System Calls • Programming interface to services provided by the OS • Typically written in a high-level language (C or C++) • Mostly accessed by programs using APIs • Three most common APIs: • Win32 API for Windows • POSIX API for POSIX-based systems (UNIX, Linux, Mac OS X) • Java API for the Java virtual machine (JVM)

24. Types of System Calls • Process Control • end or abort process; create or terminate process, wait for some time; allocate or deallocate memory • File Management • open or close file; read, write or seek • Device Management • attach or detach device; read, write or seek • Information Maintenance • get process information; get device attributes, set system time • Communications • create, open, close socket, get transfer status.

25. Why APIs? System call sequence to copy contents of one file to another Standard API

26. Reducing System Call Overhead • Problem: The user-kernel mode distinction poses a performance barrier • Crossing this hardware barrier is costly. • System calls take 10x-1000x more time than a procedure call • Solution: Perform some system functionalityin user mode • Libraries (DLLs) can reduce number of system calls, • by caching results (getpid) or • buffering ops (open/read/write vs. fopen/fread/ fwrite).

27. Real System Have Holes • OSes protect some things, ignore others • Most will blow up when you run: • Usual response: freeze • To unfreeze, reboot • If not, also try touching memory • Duality: Solve problems technically and socially • Technical: have process/memory quotas • Social: yell at idiots that crash machines • Similar to security: encryption and laws int main() { while (1) { fork(); } }

28. Fixed Pie, Infinite Demands • How to make the pie go further? • Resource usage is bursty! So give to others when idle. • Eg. When waiting for a webpage! Give CPU to idle process. • Ancient idea: instead of one classroom per student, restaurant per customer, etc. • BUT, more utilization  more complexity. • How to manage? (1 road per car vs. freeway) • Abstraction (different lanes), Synchronization (traffic lights), increase capacity (build more roads) • But more utilization  more contention. • What to do when illusion breaks? • Refuse service (busy signal), give up (VM swapping), backoff and retry (Ethernet), break (freeway)

29. Fixed Pie, Infinite Demand • How to divide pie? • User? Yeah, right. • Usually treat all apps same, then monitor and re-apportion • What’s the best piece to take away? • OSes are the last pure bastion of fascism • Use system feedback rather than blind fairness • How to handle pigs? • Quotas (leland), ejection (swapping), buy more stuff (microsoft products), break (ethernet, most real systems), laws (freeway) • A real problem: hard to distinguish responsible busy programs from selfish, stupid pigs.

30. How do you start the OS? • Your computer has a very simple program pre-loaded in a special read-only memory • The Basic Input/Output Subsystem, or BIOS • When the machine boots, the CPU runs the BIOS • The bios, in turn, loads a “small” O/S executable • From hard disk, CD-ROM, or whatever • Then transfers control to a standard start address in this image • The small version of the O/S loads and starts the “big” version. • The two stage mechanism is used so that BIOS won’t need to understand the file system implemented by the “big” O/S kernel • File systems are complex data structures and different kernels implement them in different ways • The small version of the O/S is stored in a small, special-purpose file system that the BIOS does understand

31. What does the OS do? • OS runs user programs, if available, else enters idle loop • In the idle loop: • OS executes an infinite loop (UNIX) • OS performs some system management & profiling • OS halts the processor and enter in low-power mode (notebooks) • OS computes some function (DEC’s VMS on VAX computed Pi) • OS wakes up on: • interrupts from hardware devices • traps from user programs • exceptions from user programs

32. OS Control Flow From boot main() System call Initialization Interrupt Exception Idle Loop Operating System Modules RTI

33. Operating System Structure • Simple Structure: MS-DOS • Written to provide the most functionality in the least space • Applications have directcontrol of hardware • Disadvantages: • Not modular • Inefficient • Low security

34. App App App Memory Manager File Systems Security Module Device Drivers Interrupt handlers Boot & init Extensions & Add’l device drivers General OS Structure API Process Manager Network Support Service Module Monolithic Structure

35. Layered Structure • OS divided into number of layers • bottom layer (layer 0), is the hardware • highest (layer N) is the user interface • each uses functions and services of only lower-level layers • Advantages: • Simplicity of construction • Ease of debugging • Extensible • Disadvantages: • Defining the layers • Each layer adds overhead

36. App App App File Systems Memory Manager Device Drivers Interrupt handlers Extensions & Add’l device drivers Layered Structure API Object Support Network Support Process Manager M/C dependent basic implementations Hardware Adaptation Layer (HAL) Boot & init

37. Microkernel Structure • Moves as much from kernel into “user” space • User modules communicate using message passing • Benefits: • 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 • Example: Mach, QNX • Detriments: • Performance overhead of user to kernel space communication • Example: Evolution of Windows NT to Windows XP

38. App App Memory Manager Security Module File Systems Device Drivers Interrupt handlers Boot & init Extensions & Add’l device drivers Microkernel Structure Process Manager Network Support Basic Message Passing Support

39. Modules • Most modern OSs implement kernel modules • Uses object-oriented approach • Each core component is separate • Each talks to the others over known interfaces • Each is loadable as needed within the kernel • Overall, similar to layers but with more flexible • Examples: Solaris, Linux, MAC OS X

40. UNIX structure

41. Windows Structure

42. Modern UNIX Systems

43. MAC OS X

44. Virtual Machines • Implements an observation that dates to Turing • One computer can “emulate” another computer • One OS can implement abstraction of a cluster of computers, each running its own OS and applications • Incredibly useful! • System building • Protection • Cons • implementation • Examples • VMWare, JVM, CLR, Xen+++

45. VMWare Structure

46. But is it real? • Can the OS know whether this is a real computer as opposed to a virtual machine? • It can try to perform a protected operation… but a virtual machine monitor (VMM) could trap those requests and emulate them • It could measure timing very carefully… but modern hardware runs at variable speeds • Bottom line: you really can’t tell!

47. Modern version of this question • Can the “spyware removal” program tell whether it is running on the real computer, or in a virtual machine environment created just for it (by the spyware)? • Basically: no, it can’t! • Vendors are adding “Trusted Computing Base” (TCB) technologies to help • Hardware that can’t be virtualized • We’ll discuss it later in the course