cs357 Lecture Notes Spring 2000 Week 3, Tuesday For today you should have read Sections 2.5 - 2.7. You should have read the questions at the end of the chapter, but you needn't have written answers. We'll have a quiz. For next time, read Chapter 3. It's pretty abstract and should make for a quick read. Homework 2 goes out today. Due next Tuesday. For Thursday, you should have picked up the code, compiled and run it, and started to think about what to do with the data. Also, the first exam is next Tuesday! It will cover Chapters 1-3 and the first homework. It may not take the whole class period. Caching ------- Definition: moving data up a level in the storage hierarchy, usually temporarily There are lots of variations on the idea that appear in different places. who? user explicit (tape to disk) user implicit (execute a program) compiler (memory to registers) system (virtual memory, disk to memory) hardware (L1 and L2 caches) what? how much data gets moved at a time depends on the performance characteristics of the two levels involved, the data transfer rate between them, and the access patterns 1) bigger performance gap? get more data. 2) slower transfer rate? get more data. 3) predictable access pattern? get more data. when? on demand or before (prefetching) where? (a) everywhere in the hierarchy (b) cache policy -- who goes where in the cache, who gets kicked out first why? Locality, locality, locality. 1) temporal locality: use it recently, use it soon library books, data, text suggests policies like LRU, LFU 2) spatial locality: use me, use my neighbor library books, data, text suggests policies like prefetching, large block size how? What are the implementation difficulties: 1) reliability: well, you think you wrote it, but you didn't! 2) consistency: modify a cached copy, when does the original get updated? Hardware protection ------------------- Bad name... should be interprocess protection (implemented using some special hardware features). Goal: keep processes from clobbering each other (and the OS) a) thou shalt not use more of any resource than allocated b) thou shalt not do an end-run around the OS and make uncoordinated access to shared devices c) thou shalt not read data that does not belong to you d) thou shalt not write data in space allocated to another process or the OS Note that protection is not quite the same thing as security, although there are some overlapping goals and mechanisms. 1) The goal of security is usually stated in terms of people, not processes. 2) Security worries about authentication (making sure you are who you say you are). Protection does not. 3) If you don't have protection, security is much harder. For example: if processes are well-protected, then I can let other people log in to my machine and maintain privacy. If there is no protection, then the only way to achieve security is to prevent others from logging in. How can we possibly achieve airtight interprocess protection? A little help from the hardware goes a long way. Dual mode operation ------------------- The hardware keeps track of when the OS is running and when a user process is running! 1) Assume that when the machine starts, the OS is running. 2) Before the OS start a user process, it switches to user mode. 3) Anything that causes flow of execution to return to the OS must flip the bit. Challenges: 1) OS must prove that _every_ place that executes user code throws the switch (software problem). (or else what?) 2) hardware must prove that _every_ way of getting back into the OS throws the switch (hardware/software problem) (or else what?) (what are the ways of getting into the OS?) 3) need to protect the trap/interrupt vectors (although, really, this is just another instance of protecting info that belongs to the OS -- might be in memory or in special hardware (interrupt controller)) Ok, so now we know when user/OS code is running. So what? Priviledged instructions ------------------------ The hardware can prevent user code from executing CPU instructions that perform OS functions. If they try, it causes a trap (flow returns to the OS and the process gets disciplined appropriately). Which operations need to be priviledged? I/O protection -------------- Special instructions? Make them priviledged. Memory-mapped I/O? Protect that part of memory. Memory protection ----------------- Book gives an example using a memory scheme with special registers for base and bounds. This is not a common scheme compared to virtual memory, but it makes for a simple example of how to use dual-mode operation to build memory protection. Before starting a user process, OS 1) sets the base and bound registers (remember that registers are on chip. setting registers is usually an instruction in the ISA. It would have to be protected. 2) sets the mode bit to USER 3) jumps to a known location in the user code Is it ok for the user process to _read_ the base and bound registers (assuming there is an operation that does it)? Every time the user code makes a memory access, the hardware checks the base and bounds, causing a trap if the address is out of bounds. CPU protection -------------- How do we make sure the user code eventually returns control to the OS? One way is by making a system call. Since the address of the system call is in system memory, trying to jump there causes a trap. Another way is if an interrupt occurs while the user code is running. But what if neither one happens for a really long time? What we need is the ability to generate an interrupt at a given future time. The timer does that. The OS can write a value into the timer that is decremented in real time. When it gets to zero, the hardware causes an interrupt, which returns control of the CPU to the OS. What does the OS do if there are no other processes to run?