CS 414 Review II

1. CS 414 Review II

2. Announcements • Today is the last day of class!!! • You are (almost) done! • Final, Wednesday, May 16th, 7-9:30pm (2½ hour exam) • 110 Hollister • Exam will be comprehensive, covers entire semester • Closed book, no calculators/PDAs/… • Bring ID • Sixth and final project due Thursday, May 10th • I will be out of town next week (Monday, May 7th - 10th) • return Friday, May 11th

3. What does the disk look like?

4. Disk overheads • To read from disk, we must specify: • cylinder #, surface #, sector #, transfer size, memory address • Transfer time includes: • Seek time: to get to the track • Latency time: to get to the sector and • Transfer time: get bits off the disk Track Sector Rotation Delay Seek Time

5. Disk Scheduling • FCFS • SSTF • SCAN • C-SCAN • LOOK • C-LOOK

6. RAID Levels • 0: Striping • 1: Mirroring • 2: Hamming Codes • 3: Parity Bit • 4: Block Striping • 5: Spread parity blocks across all disks • 0+1 and 1+0

7. Stable Storage Algo • Use 2 identical disks • corresponding blocks on both drives are the same • 3 operations: • Stable write: retry on 1st until successful, then try 2nd disk • Stable read: read from 1st. If ECC error, then try 2nd • Crash recovery: scan corresponding blocks on both disks • If one block is bad, replace with good one • If both are good, replace block in 2nd with the one in 1st

8. File System Layout • File System is stored on disks • Disk is divided into 1 or more partitions • Sector 0 of disk called Master Boot Record • End of MBR has partition table (start & end address of partitions) • First block of each partition has boot block • Loaded by MBR and executed on boot

9. Implementing Files • Contiguous Allocation: allocate files contiguously on disk

10. Linked List Allocation • Each file is stored as linked list of blocks • First word of each block points to next block • Rest of disk block is file data

11. Using an in-memory table • Implement a linked list allocation using a table • Called File Allocation Table (FAT) • Take pointer away from blocks, store in this table

12. I-nodes • Index-node (I-node) is a per-file data structure • Lists attributes and disk addresses of file’s blocks • Pros: Space (max open files * size per I-node) • Cons: what if file expands beyond I-node address space?

13. Implementing Directories • When a file is opened, OS uses path name to find dir • Directory has information about the file’s disk blocks • Whole file (contiguous), first block (linked-list) or I-node • Directory also has attributes of each file • Directory: map ASCII file name to file attributes & location • 2 options: entries have all attributes, or point to file I-node

14. Implementing Directories • What if files have large, variable-length names? • Solution: • Limit file name length, say 255 chars, and use previous scheme • Pros: Simple Cons: wastes space • Directory entry comprises fixed and variable portion • Fixed part starts with entry size, followed by attributes • Variable part has the file name • Pros: saves space • Cons: holes on removal, page fault on file read, word boundaries • Directory entries are fixed in length, pointer to file name in heap • Pros: easy removal, no space wasted for word boundaries • Cons: manage heap, page faults on file names

15. Managing Free Disk Space • 2 approaches to keep track of free disk blocks • Linked list and bitmap approach

16. Backup Strategies • Physical Dump • Start from block 0 of disk, write all blocks in order, stop after last • Pros: Simple to implement, speed • Cons: skip directories, incremental dumps, restore some file • No point dumping unused blocks, avoiding it is a big overhead • How to dump bad blocks? • Logical Dump • Start at a directory • dump all directories and files changed since base date • Base date could be of last incremental dump, last full dump, etc. • Also dump all dirs (even unmodified) in path to a modified file

17. File System Consistency • System crash before modified files written back • Leads to inconsistency in FS • fsck (UNIX) & scandisk (Windows) check FS consistency • Algorithm: • Build 2 tables, each containing counter for all blocks (init to 0) • 1st table checks how many times a block is in a file • 2nd table records how often block is present in the free list • >1 not possible if using a bitmap • Read all i-nodes, and modify table 1 • Read free-list and modify table 2 • Consistent state if block is either in table 1 or 2, but not both

18. FS Performance • Access to disk is much slower than access to memory • Optimizations needed to get best performance • 3 possible approaches: caching, prefetching, disk layout • Block or buffer cache: • Read/write from and to the cache.

19. Block Cache Replacement • Which cache block to replace? • Could use any page replacement algorithm • Possible to implement perfect LRU • Since much lesser frequency of cache access • Move block to front of queue • Perfect LRU is undesirable. We should also answer: • Is the block essential to consistency of system? • Will this block be needed again soon? • When to write back other blocks? • Update daemon in UNIX calls sync system call every 30 s • MS-DOS uses write-through caches

20. LFS Basic Idea • Structure the disk a log • Periodically, all pending writes buffered in memory are collected in a single segment • The entire segment is written contiguously at end of the log • Segment may contain i-nodes, directory entries, data • Start of each segment has a summary • If segment around 1 MB, then full disk bandwidth can be utilized • Note, i-nodes are now scattered on disk • Maintain i-node map (entry i points to i-node i on disk) • Part of it is cached, reducing the delay in accessing i-node • This description works great for disks of infinite size

21. LFS Cleaning • Finite disk space implies that the disk is eventually full • Fortunately, some segments have stale information • A file overwrite causes i-node to point to new blocks • Old ones still occupy space • Solution: LFS Cleaner thread compacts the log • Read segment summary, and see if contents are current • File blocks, i-nodes, etc. • If not, the segment is marked free, and cleaner moves forward • Else, cleaner writes content into new segment at end of the log • The segment is marked as free! • Disk is a circular buffer, writer adds contents to the front, cleaner cleans content from the back

22. FS Examples • DOS • Win98 • WinXP • UNIX FS • Linux ext2FS • NFS, AFS, LFS • P2P FSes

23. Network Stack: Layering Node A Application Node B Application Presentation Presentation Transport Transport Network Network Data Link Data Link Physical Physical Network

24. End-to-End Argument • What function to implement in each layer? • Saltzer, Reed, Clarke 1984 • A function can be correctly and completely implemented only with the knowledge and help of applications standing at the communication endpoints • Argues for moving function upward in a layered architecture • Should the network guarantee packet delivery ? • Think about a file transfer program • Read file from disk, send it, the receiver reads packets and writes them to the disk

25. Packet vs. Circuit Switching • Reliability: no congestion, in-order data in circuit-switch • Packet switching: better bandwidth use • State, resources: packet switching has less state • Good: less control plane processing resources along the way • More data plane (address lookup) processing • Failure modes (routers/links down) • Packet switch reconfigures sub-second timescale • Circuit switching: more complicated • Involves all switches in the path

26. Link level Issues • Encoding: map bits to analog signals • Framing: Group bits into frames (packets) • Arbitration: multiple senders, one resource • Addressing: multiple receivers, one wire

27. Repeaters and Bridges • Both connect LAN segments • Usually do not originate data • Repeaters (Hubs): physical layer devices • forward packets on all LAN segments • Useful for increasing range • Increases contention • Bridges: link layer devices • Forward packets only if meant on that segment • Isolates congestion • More expensive

28. Network Layer Two important functions: • routing: determine path from source to dest. • forwarding: move packets from router’s input to output T3 T1 T3 Sts-1 T1

29. b b 1 1 B C B C A Two connection models • Connectionless (or “datagram”): • each packet contains enough information that routers can decide how to get it to its final destination • Connection-oriented (or “virtual circuit”) • first set up a connection between two nodes • label it (called a virtual circuit identifier (VCI)) • all packets carry label 1 A

30. Name server: process running on a host that processes DNS requests local name servers: each ISP, company has local (default) name server host DNS query first goes to local name server authoritative name server: can perform name/address translation for a specific domain or zone How could we provide this service? Why not centralize DNS? single point of failure traffic volume distant centralized database maintenance doesn’t scale! no server has all name-to-IP address mappings DNS name servers

31. application transport network data link physical application transport network data link physical network data link physical network data link physical network data link physical network data link physical network data link physical logical end-end transport Purpose of Transport layer • Interface end-to-end applications and protocols • Turn best-effort IP into a usable interface • Data transfer b/w processes: • Compared to end-to-end IP • We will look at 2: • TCP • UDP

32. UDP • Unreliable Datagram Protocol • Best effort data delivery between processes • No frills, bare bones transport protocol • Packet may be lost, out of order • Connectionless protocol: • No handshaking between sender and receiver • Each UDP datagram handled independently

33. M M M M application transport network application transport network application transport network H n UDP Functionality • Multiplexing/Demultiplexing • Using ports • Checksums (optional) • Check for corruption P3 P4 application-layer data segment header P1 P2 segment H t M segment receiver

34. TCP • Transmission Control Protocol • Reliable, in-order, process-to-process, two-way byte stream • Different from UDP • Connection-oriented • Error recovery: Packet loss, duplication, corruption, reordering • A number of applications require this guarantee • Web browsers use TCP

35. TCP Summary • Reliable ordered message delivery • Connection oriented, 3-way handshake • Transmission window for better throughput • Timeouts based on link parameters • Congestion control • Linear increase, exponential backoff • Fast adaptation • Exponential increase in the initial phase

36. Remote Procedure Call • The basic model for Remote Procedure Call (RPC) was described by Birrell and Nelson in 1980, based on work done at Xerox PARC. • Goal to make RPC as much like local PC as possible. • Used computer/language support. • There are 3 components on each side: • a user program (client or server) • a set of stub procedures • RPC runtime support

37. Security in Computer Systems • In computer systems, this translates to: • Authorization • Authentication • Audit • This is the Gold Standard for Security (Lampson) • Some security goals: • Data confidentiality: secret data remains secret • Data integrity: no tampering of data • System availability: unable to make system unusable • Privacy: protecting from misuse of user’s information

38. Cryptography Overview • Encrypt data so it only makes sense to authorized users • Input data is a message or file called plaintext • Encrypted data is called ciphertext • Encryption and decryption functions should be public • Security by obscurity is not a good idea!

39. Secret-Key Cryptography • Also called symmetric cryptography • Encryption algorithm is publicly known • E(message, key) = ciphertext D(ciphertext, key) = message • Naïve scheme: monoalphabetic substitution • Plaintext : ABCDEFGHIJKLMNOPQRSTUVWXYZ • Ciphertext: QWERTYUIOPASDFGHJKLZXCVBNM • So, attack is encrypted to: qzzqea • 26! possible keys ~ 4x1026 possibilities • 1 µs per permutation  10 trillion years to break • easy to break this scheme! How? • ‘e’ occurs 14%, ‘t’ 9.85%, ‘q’ 0.26%

40. Public Key Cryptography • Diffie and Hellman, 1976 • All users get a public key and a private key • Public key is published • Private key is not known to anyone else • If Alice has a packet to send to Bob, • She encrypts the packet with Bob’s public key • Bob uses his private key to decrypt Alice’s packet • Private key linked mathematically to public key • Difficult to derive by making it computationally infeasible (RSA) • Pros: more security, convenient, digital signatures • Cons: slower

41. Digital Signatures • Hashing function hard to invert, e.g. MD5, SHA • Apply private key to hash (decrypt hash) • Called signature block • Receiver uses sender’s public key on signature block • E(D(x)) = x should work (works for RSA)

42. Authentication • Establish the identity of user/machine by • Something you know (password, secret) • Something you have (credit card, smart card) • Something you are (retinal scan, fingerprint) • In the case of an OS this is done during login • OS wants to know who the user is • Passwords: secret known only to the subject • Simplest OS implementation keeps (login, password) pair • Authenticates user on login by checking the password • Try to make this scheme as secure as possible! • Display the password when being typed? (Windows, UNIX)

43. Salting Example • If the hacker guesses Dog, he has to try Dog0001, … • UNIX adds 12-bit of salt • Passwords should be made secure: • Length, case, digits, not from dictionary • Can be imposed by the OS! This has its own tradeoffs

44. One time passwords • Password lasts only once • User gets book with passwords • Each login uses next password in list • Much easier approach (Lamport 1981) • Uses one-way hash functions User stores Server stores uid, passwd uid, n, m, H= hm(passwd) n=n-1 S = hn(password) if(hm-n(S) == H) then m=n;H=S;accept else reject uid n S

45. Security Attacks & Defenses • Attacks • Trojan Horses • Login spoofing • Logic bombs • Trapdoors • Buffer overflows • Viruses, worms • Denial of Service • Defenses • Virus Scanners • Lures • Intrusion Detection

46. Mobile Code Protection • Can we place extension code in the same address space as the base system, yet remain secure ? • Many techniques have been proposed • SFI • Safe interpreters • Language-based protection • PCC

47. Encoding Security • Depends on how a system represents the Matrix • Not much sense in storing entire matrix! • ACL: column for each object stored as a list for the object • Capabilities: row for each subject stored as list for the subject

48. Protecting Capabilities • Prevent users from tampering with capabilities • Tagged Architecture • Each memory word has extra bit indicating that it is a capability • These bits can only be modified in kernel mode • Cannot be used for arithmetic, etc. • Sparse name space implementation • Kernel stores capability as object+rights+random number • Give copy of capability to the user; user can transfer rights • Relies on inability of user to guess the random number • Need a good random number generator

49. Protecting Capabilities • Kernel capabilities: per-process capability information • Store the C-list in kernel memory • Process access capabilities by offset into the C-list • Indirection used to make capabilities unforgeable • Meta instructions to add/delete/modify capabilities

50. Protecting Capabilities • Cryptographically protected capabilities • Store capabilities in user space; useful for distributed systems • Store <server, object, rights, f(object, rights, check)> tuple • The check is a nonce, • unique number generated when capability is created; • kept with object on the server; never sent on the network • Language-protected capabilities • SPIN operating system (Mesa, Java, etc.)