Themes in OS research. Administrivia Last project due today. Functionality. Performance

Transcription

1 Administrivia Last project due today - Must hand in something by midnight even if you get extension Final Exam - Wednesday March 18, 12:15-3:15pm ingates B-01 - Open book, open notes, just like midterm - Covers material from all 19 lectures SCPD students please take in person if possible - Otherwise, cs140-staff your exam monitor s address (using subjectexam monitor) I have special office hours next Monday, 3:00-4:00pm - I also plan to be around most of the afternoon that day, so stop by if you have questions before exam Televised final review session tomorrow 4:15pm-5:05 - Bring any questions you might have on lecture material 1/34 Themes in OS research Performance Functionality System management Extensibility Power consumption Security 2/34 Performance Performance improvements always welcome - 10% is nice, but often not super interesting - 10x can actually enable new functionality Through early 90s, a major focus of OS research - Makes benefits nicely quantifiable - Let to lots of incremental work But some performance work very interesting: - Synthesis [Massalin] - OS made extensive use of dynamic code generation for speed Making logically synchronous disk accesses asynchronous [Nightingale] - Make fsync instantaneous until effects externalized - Assume NFS cache consistent, roll back execution if wrong Functionality Lots of work to make distributed systems transparent - Network operating systems (Sprite, Amoeba) - Distributed shared memory (tons of papers) - Much of this work had little impact Plan9 [Pike] make all functionality available through file namespace - Developed by the inventors of Unix, who gave up on Unix - Invented now popular abstractions such as/proc - Mount table is no longer global, but per process group - Lots of really cool benefits to unifying abstractions in FS: Bypass firewall by remotely-mounting/net Window system just virtualizes console device 3/34 4/34 System management Already talked about virtual machines Plan9 s features greatly simplified management - E.g., backups available through file system under/dump Storage management a huge deal - Large, virtual disks (e.g., Petal [Lee]) - Serverless network file systems [Dahlin] - Using desktop machines for storage (Farsite [Bolosky]) - Peer-to-peer network file systems (e.g., Ivy [Morris]) - Peer-to-peer backup (e.g., Pastiche [Cox]) Application abstraction (Singularity [Hunt]) - Avoid problems associated with installing software - Packages must describe themselves declaratively - Applications are a security principal that can go in ACLs Extensibility: Microkernels Very popular in 1980s Idea: Provide traditional OS abstractions in servers - E.g., Virtual memory server, file system server - Could Make for better fault isolation - Also makes it easier to develop new OS functionality (debugging servers potentially easier than debugging kernel) Kernel interface is very small - E.g., just provide simple IPC abstractions - Note: micro means small interface, not small code Most well-known example: Mach 3 - Big (0.5 M lines of code in 80s) and bloated - Performance problems in part from context switches - Influential system but gave microkernels a bad name More successful microkernels: VxWorks, L4, MINIX3 6/34 5/34

2 Extensibility: Other architectures Power management Big focus in mid-90s: - Inspired by applications that fight with the OS - E.g., database that has to bypass the OS buffer cache - Also CPUs still slow enough that hard to saturate net One approach: Spin [Bershad] - Download extensions into kernel using safe language - Safely run user code in kernel, saving context switch Another approach: Exokernel [Engler/Kaashoek] - Exterminate all operating system abstractions - Idea: Kernel should provide protection, not abstraction - Implement abstractions in user-level library - Replacing, e.g., socket implementation like replacing malloc Recent hot topic for sensor networks - Battery-powered devices - Deployed in environments where hard to change battery - OS techniques can extend battery lifetime from days to months Also becoming an issue for server farms - Cost of power + cooling comparable to cost of hardware Some techniques - CPU voltage scaling (requires cutting frequency when to do?) - Careful use of wireless networks - Probably will see more with disks in near future 7/34 8/34 HiStar Examples Developed by Nickolai Zeldovich here at Stanford Most software cannot be trusted - Massive, complex systems no one fully understands - Not written by security-conscious programmers - Even good programmers make mistakes Yet this is what people develop and want to run Address problem through better OS interface - HiStar: a new OS that reduces trust in software while providing Unix-like environment Symantec AntiVirus 10 contained remote exploit - Software deployed on 200,000,000 systems PayMaxx web site divulges social security numbers - Test record had SSN and no password - After login, could access records by consecutive serial number The list goes on... - CardSystems loses 40,000,000 credit card numbers - Jacobsen compromises T-mobile, steals secret service mail - Recommendation letters for 10,000 Stanford applicants stolen 9/34 10/34 Anti-virus software details What can go wrong? checks files for virus signatures daemon downloads new virus signatures How to enforce security w/o trusting software? - Must not leak contents of your files to network - Must not tamper with contents of your files writes your private data to network 11/34 12/34

3 What can go wrong? What can go wrong? sends private data to update daemon daemon sends data over network - Can cleverly disguise it in order/timing of update requests writes data to world-readable file in /tmp daemon later reads and discloses file 13/34 14/34 What can go wrong? The list goes on acquires read locks on virus database - Encodes user data by locking various ranges of file daemon decodes data by detecting locks - Discloses private data over the network can call setproctitle with user data - daemon extracts data by running ps can bind particular TCP or UDP port numbers can relay data through another process - Call ptrace to take over process, then write to network - Use sendmail, httpd, or portmap to reveal data Disclose data by modulating free disk space Can we ever convince ourselves we ve covered all possible communication channels? 15/34 16/34 Information flow control Reasoning about operations is hard - Can you enumerate all permissible actions by scanner? - What about helper programs spawned (gzip, ar, mime,... )? - What about any process that can observe scanner? Reasoning about information flow is easier - Policy: Don t write my files to network unless I say so Restructure OS to make all information flow explicit - Has been done in a very heavy-weight fashion for military - Give individual users control over information flow - Allows us to restructure applications with less trusted code Linux Security checks Hardware HiStar architecture HiStar Security checks Hardware Kernel provides small number of simple objects - Simple enough that information flow is unambiguous 17/34 Layer Unix API as untrusted library on top of kernel 18/34

4 HiStar kernel objects Unix processes Only six types of object exposed by kernel interface Unix abstractions built from HiStar objects But implemented in untrusted library code - E.g., a bug in the code implementing processes won t violate information flow restrictions 19/34 20/34 Example: File descriptors in Unix Example: File descriptors in HiStar Suppose A can t flow to B, but they share a file desc. Typical mistake: Consider read-only fd to be okay - But even a read-only fd has mutable state, such as offset pointer - Hard to catch all such shared state Implemented in terms of lower-level HiStar objects - Seek pointer must be stored in labeled segment - Ensures it can t be used to leak information 21/34 22/34 What s in a label? Labels represents 2 types of information flow concern - secrecy preventing people from observing information - integrity preventing people from modifying information Each concern is represented by a category of taint Secrecy categories shown as - Different colors represent different secrecy categories - Secrecy category in label object tainted in that category Integrity categories shown as - Integrity category in label object less tainted in that category L A L B ( L A can flow to L B ) when: - L A is no more tainted than L B in every category - I.e., L A has all integrity categories in L B and L B has all secrecy categories in L A 23/34 Recall: Bell-LaPadula labels top-secret, {Nuclear, Crypto} top-secret, {Nuclear} secret, {Nuclear} top-secret, secret, X top-secret, {Crypto} X X secret, {Crypto} L 1 L 1 means L 1 L 2 unclassified, Information can only flow up the lattice - System enforces No read up, no write down 24/34

5 HiStar labels Downgrading privileges Downgrading privileges are decentralized ( ) - Represented by per-category stars in threads labels ( ) - Means thread can ignore taint in that category Any thread can create a new category - You get the stars for the categories you create Can implement Unix UIDs using categories - Each UID u corresponds to two categories: An integrity category, u i and, a secrecy category, u s - u s shell gets those stars whenever s/he logs in - File with 0644 permissions (-rw-r--r--) is labeled w. u i Can add but not remove secrecy categories Can remove but not add integrity categories - File with 0600 permissions (-rw ) labeled w. both u s, u i Can implement other policies alongside UIDs 25/34 26/34 Example: virus scanner Example: ssh-agent tainted, so cannot write to network Dynamically allocated also prevents scanner from corrupting files ssh-agent stores your private key - Want to prevent even root from getting the key - ssh-agent can just allocate its own secrecy category 27/34 28/34 Runaway processes Containers What if ssh-agent goes nuts? - Can allocate lots of categories, cut itself off from the world! Separate resource allocation from access control Can reclaim resources if you can write container - Even if you can t read or write the objects you are deleting 29/34 30/34

6 Other HiStar applications Web server Untrusted login Red-green VPNs Web server for untrusted CGI scripts (next slide) Distributed HiStar Ongoing/future work: - Scheduler resource control for reducing timing channels - New applications written by untrusted programmers - Allowing policies to apply to power management (for mobile devices) 31/34 32/34 Final thoughts You are all now operating systems experts Use this knowledge to build better applications - Sometimes need to coax right behavior out of kernel - Should be much easier now that you know what s going on Syscall interface can be an innovation barrier - Much harder to change kernel than user code - Other examples include standardized net. protocols, servers - Get these wrong and many people will suffer Some of you will go on to design interfaces that many people are later subjected to - Strive to achieve both simplicity and flexibility for users How to learn more about OSes Take CS240 Advanced Topics in Operating Systems - Class will bring you up to speed on OS research - Read & discuss research papers - By the end, should be ready to do OS research Get involved in research! Lot s of interesting OS work at Stanford - Rosenblum launched the virtual machine resurgence - Lam collective system, software for mobile devices - Levis seminal work on sensor nets & power management - Engler tools to find OS bugs automatically - Boneh/Mitchell lots of practical OS security work - Mazières file system and security research 33/34 34/34