DOC PREVIEW
Stanford CS 140 - CS 140 Lecture Notes

This preview shows page 1-2 out of 7 pages.

Save
View full document
View full document
Premium Document
Do you want full access? Go Premium and unlock all 7 pages.
Access to all documents
Download any document
Ad free experience
View full document
Premium Document
Do you want full access? Go Premium and unlock all 7 pages.
Access to all documents
Download any document
Ad free experience
Premium Document
Do you want full access? Go Premium and unlock all 7 pages.
Access to all documents
Download any document
Ad free experience

Unformatted text preview:

AdministriviaConfining code with legacy OSesUsing chrootEscaping chrootSystem call interpositionLimitations of syscall interpositionReview: What is an OSWhat ifldots How is a process different from HW?Virtual Machine MonitorOld idea from the 1960sVMM benefitsDifferent thought about OSesOS backwards compatibilityIsolation & Multi-level securityLogical partitioning of serversExample: VMMs for IDSVMM-based IDSCollective Project href {http://suif.stanford.edu/papers/nsdi05.pdf}{[Chandra]}Complete Machine SimulationVirtualizing the CPUVirtualizing trapsVirtualizing memoryShadow page tablesShadow PT issuesTracingTracing vs. hidden faultsI/O device virtualizationCPU virtualization requirementsBinary translationVMware binary translatorControl transferNon-identically translated codeAdaptive binary translationESX mem. mgmt. href {http://www.scs.stanford.edu/10wi-cs140/sched/readings/esx.pdf}{[Waldspurger]}Reclaiming pagesSharing pages across VMsIdle memory taxFinal thoughtsHow to learn more about OSesAdministrivia• Guest lecture Thursday- Amit Singh (Google): Real-world Operating Systems-Please attend lecture if at all possible• Last project due Thursday-No extensions unless all non-SCPD group members at lecture- If staff grants you extension, means only if you attend lecture- We will have a more stringent enforcement mechanism•Final Exam- Thursday March 18, 12:15-3:15pm- Open book, covers all 19 lectures(possibly including topics already on the midterm)• Televised final review session Friday- Bring questions on lecture material1/40Confining code with legacy OSes• Often want to confine code on legacy OSes• Analogy: FirewallsHopelesslyInsecureServerattackerattacker- Your machine runs hopelessly insecure software- Can’t fix it—no source or too complicated- Can reason about network traffic• Similarly block unrusted code within a machine- By limiting what it can interact with2/40Using chroot• chroot (char *dir) “c hanges ro o t directory ”- Kernel stores root directory of each process- File name “/” now refers to dir- Accessing “..” in dir now returns dir• Need root privs to call chroot- But subsequently can drop privileges• Ideally “Chrooted process” wouldn’t affect parts ofthe system outside of dir- Even process still running as root shouldn’t escape chroot•In reality, many way s to cause damage outside dir3/40Escaping chroot• Re-chroot to a lower directory, then chroot ..- Each process has one root directory, so chrooting to a newdirectory can put you above your new root• Create devices that let you access raw disk• Send signals to or ptrace non-chrooted processes• Create setuid program for non-chrooted proc. to run• Bind privileged ports, mess with clock, reboot, etc.• Problem: chroot was not originally intended forsecurity- FreeBSD jail, Linux vserver have tried to address problems4/40System call interposition• Why not use ptrace or other debugging facilities tocontrol untrusted programs?• Almost any “damage” must result from system call- delete files → unlink- overwrite files → open/write- attack over network → socket/bind/connect/send/recv- leak private data → open/read/socket/connect/write . . .• So enforce policy by allowing/disallowing eachsyscall- Theoretically much more fine-grained than chroot- Plus don’t need to be root to do it•Q: Why is this not a panacea?5/40Limitations of syscall interposition• Hard to know exact implications of a system call- Too much context not available outside of kernel(e.g., what does this file descriptor number mean?)- Context-dependent (e.g., /proc/self/cwd)• Indirect paths to resources- File descriptor passing, core dumps, “unhelpful processes”• Race conditions- Remember difficulty of eliminating TOCCTOU bugs?- Now imagine malicious application deliberately doing this- Symlinks, directory renames (so “..” changes), . . .• See[Garfinkel] for a more detailed discussion6/40Review: What is an OS• OS is software between applications and reality- Abstracts hardware and makes portable- Makes finite into (near) infinite- Provides protection7/40What if. . .• The process abstraction looked just like hardware?8/40How is a process different from HW?Process Hardware•CPU – Non-Privilegedregisters and instructions.• Memory – Virtual memory.• Exceptions – signals, errors.• I/O – File System, Directory,Files, raw devices.• CPU – All registers andinstructions.• Memory – Both virtual andphysical memory, memorymanagement, TLB/pagetables, etc.• Exceptions – Trap architecture,interrupts, etc.• I/O – I/O devices accessed us-ing programmed I/O, DMA,interrupts.9/40Virtual Machine Monitor• Thin layer of software that virtualizes the hardware- Exports a virtual machine abstraction that looks like thehardware10/40Old idea from the 1960s• See[Goldberg] from 1974• IBM VM/370 – A VMM for IBM mainframe- Multiplex multiple OS environments on expensive hardware- Desirable when few machine around• Interest died out in the 1980s and 1990s- Hardware got cheap- Compare Windows NT vs. N DOS machines• Interesting again today- Different problems today – software management- VMM attributes still relevant11/40VMM benefits• Software compatibility- Runs pretty much all software- Trick: Make virtual hardware match real hardware• Can get Low overheads/High performance- Near “raw” machine performance- Direct execution of CPU/MMU• Isolation- Seemingly total data isolation between virtual machines- Use hardware protection• Encapsulation- Virtual machines are not tied to physical machines- Checkpoint/Migration12/40Different thought about OSes• Installing software on hardware is broken- Tight coupling of OS and applications to hardware createsmanagement problems• Want to subdivide OS:- Hardware drivers- Hardware management- System support software• Turn OSes into normal software that can be manag e d13/40OS backwards compatibility• Backward compatibility is bane of new OSes- Huge effort require to innovate but not break• Security considerations may make it impossible- Choice: Close security hole and break apps or be insecure• Example: Not all WinNT a pplications run on WinXPor XP on Vista- In spite of a huge compatibility effort- Given the number of applications that ran on WinNT,practically any change would break somethingif (OS == WinNT) . . .• Solution: Use a VM M to run both WinNT and WinXP- Obvious for OS migration as well:


View Full Document

Stanford CS 140 - CS 140 Lecture Notes

Documents in this Course
Homework

Homework

25 pages

Notes

Notes

8 pages

Load more
Download CS 140 Lecture Notes
Our administrator received your request to download this document. We will send you the file to your email shortly.
Loading Unlocking...
Login

Join to view CS 140 Lecture Notes and access 3M+ class-specific study document.

or
We will never post anything without your permission.
Don't have an account?
Sign Up

Join to view CS 140 Lecture Notes 2 2 and access 3M+ class-specific study document.

or

By creating an account you agree to our Privacy Policy and Terms Of Use

Already a member?