cs341 Lecture Notes Spring 2002 Week 2, Monday For today you should have: 1) Read Section 3.2 Basic Functions and Sections 4.1 through 4.4 Answer the preparation questions at the end of the notes. 2) Started hw01, which is due Thursday. There's nothing to turn in for this homework. 3) Read and solved the next semaphore puzzle, mutual exclusion. 4) Prepared for a quiz. For next time you should: 1) Read Section 3.3 2) Finish hw01. 3) Solve the next semaphore puzzle. 4) Start hw02. It's due next Thursday. Here are the assignments for partners: Cameron Schwenck Siyam Chang Muenchow Pollard Choy Mushtaque Train Ahmad Wada Wan Carlin Eusuf Golder Connor Stadler Masiello (around the room for mutual introduction) Preparation questions: Nutt Chapter 4 ------------------------------------- Go back to notes02.txt and review answers to the preparation questions. Quiz ---- Semaphores ---------- Why is it not ok for threads to execute count++ concurrently? Mutual exclusion solution. Reading notes: Nutt Section 3.3 ------------------------------- This section is not Nutt's finest hour. Please make what you can of it, then read my notes below. Processor modes --------------- 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 starts 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?) 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 -------------- There are two ways to access I/O devices, either with special instructions or with special memory locations: Special instructions? Make them priviledged. Memory-mapped I/O? Protect that part of memory. Memory protection ----------------- In a virtual memory system, how does the operating system prevent a process from accessing memory that does not belong to it? In effect, it doesn't have to. Processes generate virtual addresses, which the OS translates into physical addresses. If a process generates a good VA, the OS translates it into a PA and fetches the data. If a process generates a bad VA, the OS terminates the process. There is no way for a process to generate a PA at all. BUT (and it's a very big BUT) remember that the operating system uses a TABLE to translate addresses. What would happen if a process could modify that table? Is it ok for the user process to _read_ the table? CPU protection -------------- How do we make sure the user code eventually returns control to the OS? One way is by making a system call. Making a system call actually executes a stub, which executes an instruction that causes a trap. The trap returns control to the operating system, and switches the mode bit to kernel mode. The OS figures out what system call was invoked and jumps to the appropriate place in kernel code. 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?