Lecture Notes for Wednesday, April 13 by Ramy Dodin Topic 1: Cache Consistency – Mainly mentioned in hardware context, i.e. with multiprocessor systems- -One issue is that in a system with caching there can be many copies of a given piece of data, and maintaining the coherency of this datum in itself represents a difficult problem to engineer a solution to. -If any of those pieces is written, it becomes inconsistent with other pieces, and thus we must either update the rest, or invalidate the rest, which then diminishes the performance of our system. -Such problems are not only a feature of distributed systems, but plague on-die CPU caches as well -Goal of technology: to design a distributed system (or shared file system) that yields the same results as a unified, uniprocessor system (some modern success on this front). -Caching can occur in disk, controller, in SAN or NAS, or in main memory disk cache, to name the major techniques. Other, less prominent caching schemes exist. -A potential solution: maintain only one cached copy at a time -However this is highly inefficient if the file is read-only or “read-mostly”, in other words writes occur so rarely that the loss inherent in being unable to let everyone cache a particular line is not really justified in this case because most of the use of that data is for read purposes. A good example is a library record. Perhaps it changes once every three years, but when that happens, go ahead and fish around for all the copies and update them; in the meantime let everyone have their cached copy. -Optimistic approaches: -Don't lock files, and hope optimistically that everything stays coherent (bad idea) -Don't lock anything, but keep around some old copy of the data. Backout of a transaction if necessary -Leave it to users to worry about managing these issues (the tack taken in unix and database systems) -Note: we need to know where and how to find all of the copies of the data: -In distributed systems, there is no way to do “snoop” coherence, as seen in multiprocessor systems i.e. one particular node of a system can't see all block and file requests. -The system “owning” the file (usually the processor of the system where the files lives) must keep track of who has copies. -If broadcast-writes is used, we can give a list of cached copies to any system writing the data -False sharing: a block is shared, but the data in it isn't shared. i.e. process A is using subset X of the block and process B is using subset Y of the block, yet X and Y don't overlap. -This problem can have a big effect on the performance of a cache consistency scheme. -Write merge: in a situation where there are several writes to a block, while the data still resides within the cache and before it is written back to disk, we merge the writes into one “uberwrite”, so that only one big cumulative update is written back. This is like shopping at Costco rather than Berkeley Bowl. Topic 2: Process Migration -We want to take a running process and move it to another machine. - -This can get tricky because we must have a unified and transparent file system. Moreover, we must have compatible platforms and architectures. Other challenges include: (a) The need to save and transfer state. (b) The need to maintain all connections (to OS, to network, to other systems to I/O devices, to the filesystem). (c) Connections can be forwarded with care. (d) Connections can be reconnected with care. -Obviously this scheme is unworkable if the CPU architecture is different. (object code won't run) -Very hard if OS on other end is different. -They must be interoperable, complete with all the same system calls, interrupts, and multithreading features. -One big motive for parallelism and distribution: heat and power consumption -Digression: heat and power consumption has emerged as a big issue in buildings with large numbers of machines running. One solution is to pump cooling fluid through the actual machine casings. A refugee camp heated with large servers is envisioned before we finally reconverge to our subject matter-at-hand. Topic 3: Parallel Programming and Amdahl's Law -N processors will never get you an N-times speedup -Some critical part of a computation may in general not be parellizable (at least the code that distributes and gathers the computation is not parallizable). -This has been touted as the “technology of the future” for 40 years, however now that we're brushing up against the limits of the hardware the technology is finally moving seriously in that direction. --------------------------NEW SUBJECT ALTOGETHER--------------------------- Topic 4: Protection and Security -The purpose of a protection system is to prevent accidental or intentional misuse of a system while permitting controlled sharing. It is relatively easy to provide complete isolation, though this may not always be viable. (e.g. one unnetworked machine in locked room with armed guards at door. -Potential accidents: - E.g. A program mistakenly overwrites the file containing the command interpreter. As a result no one else can log in. Problems of this kind are easy to solve, or at least the likelihood of such failures is reducible to a workable extent. -You accidently destroy a file you'd like to keep (i.e. loose protections). -Malicious abuse (harder to prevent obviously). -Speed dialing of IP addresses -Script Kiddies -Smith admits to joking about the issue, but reminds us of problem's seriousness. -We are concerned with 3 kinds of effects: -Unauthorized information modification. (e.g. change of cs162 grade) -Unauthorized denial of use. (e.g. million emails sent to cs162-tb) -Unauthorized information release. (e.g. the age of Smith's transparencies) -The biggest complication in a general purpose remote accessed computer system is that the intruder in these definitions may be an otherwise legitimate user of the system. When faced with this situation we have to address a new tradeoff, which is inconvience faced by ethical users and the propensity to dimiss overly intrusive or cumbersome security measures. -Examples of problems not yet solved. Note that these include so-called “social engineering” issues, and are not necessarily computer problems: -Fake timesheets for paychecks. -Repeat button printer to print extra paychecks. (poor design with serial number pre-stamped on printer paper) -Round off amounts and put into special account. -Make up deposit slips with your account number on them. -Make up checks with your name, but some other account number on them. (Paid out of other account). -Functional Levels of Information Protection -Unprotected System- very common, source of many DOS attacks and worms. - All or nothing system (i.e. sharing as in an open lab, or complete isolation as in CIA). -The simplest type of protection system is just a user/system distinction. -Someone with "system" privileges can do anything. A user can only do things at a user access level permitted to him. -Obviously, this is unsatisfactory. We need to differentiate between users, and given more fine grained access. ex. One person submitted fraudulent deposit slips in drop box. Philosophy: Societies function reasonably because the right thing to do is in you advantage. So in the US the economy is flexible enough is that it behoves you to behave honestly; whereas in the third world where there is limited opportunity going crooked makes more sense. The people smart enough to come up with such scams are smart enough to go straight and make a huge pile of cash. -Controlled sharing is an alternative paradigm. -User programmed sharing controllers allow flexibility in granting access privileges to various users. For example a user wants to put complex restrictions on use, such as time of day, or concurrence of another user. -Design principles for protection mechanisms: 1) Economy of mechanism: keep the design as simple and small as possible. (KISS - keep it simple, stupid.) 2) Fail safe defaults: base access decisions on permission, not exclusion. If the system fails, the default is lack of access. 3) Complete mediation: every access to every object must be checked for authority. This can be slow and cumbersome, however. 4) Open design: the design should not be secret. Its effectiveness should not be impaired by knowledge of the mechanism. This flies in the face of ultra complicated security products that actually, in the end, seem to not do much better than free, open source solutions and time-tested standards. 5) Separation of privilege: where feasible, a protection mechanism that requires two keys to unlock it is more robust than one that allows access to the presenter of only one. This must be sanity-checked with real world common sense, i.e. two keys to launch a missile, but the two keyholes are less than an armspan apart, so one guy kills the other, takes his key, and turns both himself at the same time so he can reach. If they were further apart at least he would need an accomplice. 6) Least privilege: give no more than the required access. Again this may be tough in large organizations where it leads to slowing down the work, i.e. of an engineer who needs a product spec on a “hot and forthcoming” product. 7) Least common mechanism: minimize the amount of mechanism common to more than one user and depended upon by all users. (These represent the information paths.) 8) Psychological acceptability: human interface must be convenient! If it's too hard to implement than people will get lazy and make mistakes. -There are three aspects to a protection mechanism: I. Authentication: Confirm that the user is who he says he is. II. Authorization determination: we must figure out what the user is and isn't allowed to do. A simple database can suffice for this role. III. Access enforcement: we must make sure there are no loopholes in the system. ***Even the slightest flaw in any of these areas may ruin the whole protection mechanism. *** -Authentication is most often done with passwords. This is a relatively weak form of protection for reasons clarified below. -A password is a secret piece of information used to establish the identity of a user. -Passwords can be compromised in a number of ways: -Can be stolen (you write it down somewhere: wallet, address book, front of terminal) -One story relates a villain who looked in the waste basket of the guy charged with adding new passwords. -Story of guy (on CTSS) who logged on at midnight (when system administrator was on), expanded his segment and got copy of password segment of system administrator. -Line can be tapped and password copied -Password can be observed as typed in. -Password can be guessed (your name, your mother's name, your project, your birthday). -Password can be repeatedly tried. (Should not be permitted). -Password file can be broken. -For all these reasons, passwords are regarded as a lightweight protection mechanism. -Countermeasures: -Passwords should not be stored in a directly-readable form. One-way transformations should be used. -Use a one-way function. Given a copy of the password file, can't invert the transformation to get back to the password. (Unix does this. Password file (/etc/passwd) is readable.) -Unix also uses "SALT" to extend the password. -Idea is that salt (e.g. user ID) is concatenated to password before encryption. -This prevents efficient generation of file of encrypted common passwords for comparison. -Password testing should be slow, to discourage machine based tests. -Limit the number of tests. -Passwords should be relatively long and obscure. Paradox: short passwords are easy to crack, long passwords are easily forgotten and usually written down, which enhances the likelihood of malicious discovery. -Password testing programs (using common names, words, etc.) often can break more than half of the passwords in the system. -Tell the user when he last logged in; this way he can tell if there was an intruder. -Note: we must protect the authorizer. The program that checks whether the password matches (or encrypts the password) must be incorruptible. -(If there is physical security, must be sure guards are incorruptible.) -Another form of identification: badge or key. -Benefit is that it doesn't have to be kept secret. -Should be unforgeable and uncopyable. -Can be stolen, but the owner should know if it is. -These physical tools are a hassle to carry. -Key paradox: key must be cheap to make, hard to duplicate. This means there must be some trick (i.e. secret) that has to be protected. -Once identification is complete, the system must be sure to protect the identity since other parts of the system will rely on it. -That is, the system must be sure that once a given process is associated with a given user, that the correspondence is retained. -E.g. you don't want to be able to forge mail.