COP 3402 meeting -*- Outline -*- * Interrupt Mechanism Based on Chapter 8 of Systems Software by Montagne and Operating Systems: Three Easy Pieces by Arpaci-Dusseau and Arpaci-Dusseau (see https://pages.cs.wisc.edu/~remzi/OSTEP/) ** Problem being Solved ------------------------------------------ WHY HAVE INTERRUPTS? How to share resources on a computer? A. Provide libraries to access resources trust users will not take advantage Is that practical? B. State policies about sharing humans penalized if violate policy Is that practical? C. Enforce polices about sharing at runtime, before harm is done Is that practical? ------------------------------------------ ... no! - programs can make mistakes could accidentally wipe out data from other users would be harder to debug if other programs could interfere ... no! - things happen too fast loss of information might not be recoverable loss of confidentiality might not be visible can't expect programmers to update programs when policies change ... yes! - checks at speed of processor - stop loss of information or confidentiality before it happens - automatic enforcement even if programmers don't maintain programs ** Needs for Interrupt Mechanisms ------------------------------------------ INTERRUPT MECHANISM Goal: enforce polices on sharing, privacy, etc. How could the OS enforce policies? a. OS and user have same permissions b. OS has more permissions c. OS has fewer permissions What would help OS enforce policies: 1. users cannot read some data 2. users cannot write some data 3. users cannot execute some instructions ------------------------------------------ a and c won't work, as user could "accidentally" wipe out any information being kept on permissions, user actions imagine if you could make police forget you were speeding... But in b, OS can safely record information about policies and behavior of users 1 doesn't help with keeping records 2 helps some, but if don't have 3, then can't stop user processes from taking control of the machine 3 is needed to stop user's from doing bad things imagine a world of wizards that can make anything happen, how to stop crimes? ** How interrupts work ------------------------------------------ INTERRUPT MECHANISM Hardware: 1. Instructions added to signal interrupt events 2. At end of each fetch-execute cycle, the CPU checks for interrupt events ------------------------------------------ Q: Should signaling an interrupt be a privileged instruction? No, user code might encounter such situations *** traps ------------------------------------------ TRAPS def: a *trap* is an interrupt that occurs due to Examples: What should be done for traps? ------------------------------------------ ... a program error or malicious action ... division by zero, arithmetic overflow (OV flag) ... stop the computer and notify the operator (in old days) Is that flexible? What if there is no operator? Better: do some custom action under program control ------------------------------------------ INTERRUPT HANDLERS def: an *interrupt handler* is code that How? When an interrupt is noticed: jump to ------------------------------------------ ... is run whenever a (certain kind of) interrupt occurs ... code to handle it (based on the type of interrupt) the handler: - saves the running process's state - jumps to appropriate code (depending on type of interrupt) Why save the state of the running process? So it can be resumed (this also helps with debugging/forensics in case it's an error or malicious) *** I/O interrupts ------------------------------------------ I/O INTERRUPTS When device completes an operation it sets a bit in the CPU and then the OS: - suspends the running process - calls an interrupt handler ------------------------------------------ Q: What hardware is needed for this? A flag to indicate an interrupt is waiting Q: Do I/O interrupts need to be handled quickly? Yes, the information may be lost otherwise *** Timer interrupts ------------------------------------------ TIMER INTERRUPTS When a process uses up a time slice it sets a bit in the CPU and then the OS: - suspends the running process - calls an interrupt handler to schedule another waiting process Would it be better to wait for another running process? ------------------------------------------ ... no, another process might go into an infinite loop! Q: Do timer interrupts need to suspend the running process? Yes, otherwise it could go on forever! *** multiple interrupts ------------------------------------------ MULTIPLE INTERRUPTS What if: - multiple interrupts happen at the same time? - if an interrupt happens when handling another interrupt? Possible problems: ------------------------------------------ Can turn off some interrupts during handling an interrupt to prevent some (but not all) of this Need to prioritize interrupt handlers, so that higher priority ones can interrupt lower priority handlers One approach is to divide interrupt handling into 2 levels: first-level: just records time-sensitive information and schedules a process to do the real work second-level: scheduled as a kernel thread, run when there is time ... livelock (system only works on interrupts) ** maintaining OS control ------------------------------------------ LIMITED DIRECT EXECUTION Goals: a. Run programs efficiently b. Share resources c. Prevent bad behavior Approach: For efficiency: For sharing and enforcing good behavior: Execution modes: Hardware support: ------------------------------------------ ... run user programs directly on the CPU (they run at 100% of speed) ... don't allow user programs to execute some instructions and protect some areas of memory ... user mode - can't execute privileged instructions system (kernel) mode - can execute privileged instructions This needs hardware support - a mode flag trap if user mode tries to execute privileged instruction - an address fence: - prevents user programs from writing OS area of memory (say addresses from 0 to 3K) Q: What should be the mode when a computer is booted? Start in system (kernel) mode, to initialize the hardware, including trap tables Q: What should the mode be when running a user program? User mode! Q: How does this maintain control of user processes? They can't do anything dangerous Any time they request a service from the OS, then the OS can carefully examine the request... *** system calls ------------------------------------------ INTERRUPTS AND SYSTEM CALLS Interrupt (trap, int, or svc) instruction - not privileged but starts system (kernel) mode - runs some specified code based on a (trap) table Return-from-trap instruction: - like procedure return instruction that specifies location of the trap table - privileged System call: - is a normal library function call - saves state (registers, PC, etc.) - pushes arguments on stack - sets the system call number (in a register) - executes interrupt instruction (pushes PC, saves process state on a kernel stack -- one per process, starts kernel mode, indirect jump through trap table to specialized code) (return-from-trap restores process state from kernel stack, starts user mode, restores PC) - adjusts any results on runtime stack (or in a register) - returns to caller ------------------------------------------ Q: What could happen if the instruction that specified the location of the trap table were not privileged? User processes could take over the machine, because the handler runs in kernel mode! Q: Why don't you need to use the trap instruction in your own code? Because it's already written in a library function (the system call's code has it, in assembly language) Q: Why is a stack needed in the kernel per process? To save the state of the system call, so can return to it So system calls from one process don't interfere with others Q: Do libraries that run system calls need to be careful? Yes! There could be security problems or other problems if not! Q: Do system call library functions need to be fast? Yes, because it's monopolizing a shared resource (the CPU) ------------------------------------------ INTERRUPT VECTOR OR TRAP TABLE def: an *interrupt vector* or *trap table* is an array of starting addresses for Why use a table? ------------------------------------------ ... interrupt handlers ... To save time in handling interrupts (the interrupt code from the PSW is used as an address or offset into this table of addresses; the OS does an indirect jump through this table) Q: How does the trap table get initialized? The OS does it during boot time *** Memory Protection ------------------------------------------ NEED FOR MEMORY PROTECTION On interrupt: hardware runs interrupt handler from What happens if a user program can write those locations? ------------------------------------------ a set location (or table of locations determined by the OS at boot time) then the user can run arbitrary code in privileged mode! so: the user can take control of the machine! ------------------------------------------ HOW TO PROTECT MEMORY How to prevent users from writing over code for interrupt handler(s)? Is hardware needed? Are changes to instructions needed? ------------------------------------------ ... - cause a trap when user process tries to write into protected area of memory - OS can then kill the offending process ... Yes, need to monitor the CPU's actions, can't interrupt for each memory access (too expensive) Hardware: - memory fence register (addresses between 0 and that address are protected from user process writes) - device to compare addresses - bit to set (flip/flop) if a violation occurs ... Changes to instruction processing (CPU): - change store (and other memory writing instructions) to check for memory protection violations before writing to memory (this could be done in microcode) Q: What does "segmentation fault" mean for a C program? It's a memory protection violation (On some older computers memory was divided up into "segments" like text and data and a user program could only write into its own data segment) *** Privileged (Supervisory) Mode ------------------------------------------ PRIVILEGED MODE Okay for a user process to change the fence register? Privileged mode: Hardware needed: ------------------------------------------ ... No, this is another case where privileged mode is needed ... A CPU mode that allows execution of all instructions (changing the fence register, setting code for interrupt handlers, etc.) Comparison hardware in the CPU to detect privileged instructions (e.g., all have an opcode greater than some number) Q: What should happen if a user process executes a privileged instruction? A trap occurs... So, need a bit to indicate a violation *** Program Status Word Q: Are we accumulating a lot of conditions for traps? Yes, we need some place to keep track of them, hence the... ------------------------------------------ PROGRAM STATUS WORD Program status word is a (privileged) register containing: ------------------------------------------ ... interrupt flags process's mode -- user or privileged PC condition code(s) interrupt masks (which ones are disabled) (Term comes from the IBM System/360)