Cute Tricks with Cute Tricks with Virtual Memory Virtual Memory A short history of VM A short history of VM Memory used to be quite limited. (and why they don’t work) (and why they don’t work) Use secondary storage to emulate. Either by swapping out whole processes, or by CS 614 9/7/06 CS 614 9/7/06 paging out individual pages. by Ari Rabkin by Ari Rabkin Old technology -- done in the 60s. Program is oblivious. How paging works How paging works Paging, continued Paging, continued Hardware translates each mem. operand from Divide RAM into fixed size (4k?) pages. virt. to phys. (Much too slow otherwise) Hardware typically has map from virtual Uses a translation lookaside buffer (TLB) that’s address to physical page. (Page table). typically a fast associative cache. Each page table entry also has valid bits, mode Details of page tables, TLB vary from bits, etc. architecture to arch. 4 Key questions Key questions Flash forward... Flash forward... How architecture-independent can an OS’s VM Modern systems aren’t RAM constrained: system be? So what do we do with all the VM hardware? What else can we do with VM? Lot of possible uses explored, e.g., memory mapping files. See Appel and Li for details. VM hardware gives the OS complete mediation of app memory access -- very Examples: Garbage collection, guard pages, powerful! etc etc. Who gets to do it? What is VM, fundamentally? 1
What is VM really ? The Mach Vision What is VM really ? The Mach Vision Virtual memory isolates process memory Want to build the next generation Unix: Separation is key tool for security More portable, more flexible Can poke holes in interprocess barriers to Accent system showed you could use memory allow IO or interprocess communication. mapping for fast IPC. Shared memory IPC, remapping to send Why not move most of OS into user space, just messages, etc. use kernel for (memory-based) IPC? The mach vision The mach vision mach VM system mach VM system Want to minimize arch. dependence, and keep IPC via messages sent through ports to tables small. threads But page tables are architecture-specific. Fork needs to be cheap, so want to use copy- on-write extensively Solution: keep machine indep. data structures, machine-dep. structures are purely a cache. Push paging into userspace, for flexibility. Authoritative copy is maintained by machine- Also, want to reduce size, cost of pagetables independent parts of Mach. Handling forks Handling forks Structures Structures A few key data structures Unix typically uses lots of small processes, created via fork. Want to make this fast. Per-process Address maps to define regions (small!) Typically, every process needs its own page table. Machine-independent (inverted ) page table (one per system) Page tables are expensive and bulky; how to reduce overhead? Memory objects to hold actual backing store 2
Mach’s interface Lessons Mach’s interface Lessons Exposes powerful low-level interface. Really is possible to build a largely machine- independent VM system. Radically improves portability. Very flexible: pagers can live in user space Can even make it fairly fast! But is it really fast? How can this be fast? How can this be fast? But is it really fast? Often, arch’s page tables aren’t quite right for If Mach is so fast, how come nobody uses it? the OS. VM system isn’t the whole OS: messaging Better to use machine-indep format that’s really hurts a lot. right, and then can be flexible in how arch. pages tables are used. Security checks on messages are expensive: most of the expense of IPC is the check. (See Who designs better data structures: the L3/L4 papers for how to make IPC fast) Programmers or chip designers? Mach didn’t make it fast. Too much overhead on the critical path. Hardware changes Hardware changes L4 syscall results L4 syscall results Hardware has changed since Mach CPUs getting faster, faster than RAM. Caching critical. Bigger (more important) caches Microkernels don’t play nice here: dump cache on the [frequent] context switches. See Chen and Bershad 93 Conclusion: Cost of syscall is from Mach, not microkernels generally. 3
The End of The µ-Kernels Why Asbestos? The End of The µ-Kernels Why Asbestos? Servers typically touch data for many users. Linus Torvalds: “Essentially, trying to make microkernels portable is a waste of time. It's Bugs may allow user A to read data from part like building an exceptionally fast car and of server talking to user B. putting square tires on it. The idea of Want to have outside enforcement of isolation abstracting away the one thing that must be of different user’s data. blindingly fast--the kernel--is inherently counter-productive.” Normal processes too heavyweight; need [ http://www.oreilly.com/catalog/opensources/book/linus.html ] something lighter. What is Asbestos? What is Asbestos? Event Processes Event Processes Idea: have event processes where different Research OS, designed to have data flow instances share most of address space, but not labels everything. Strong compartmentalization to limit damage Just a few pages separate--for user-specific from user-level compromises. data. Fires don’t spread OS alters pagetables for just those pages on Key question: how much does it all cost? context switch What does it cost? What does it cost? Asbestos Throughput Asbestos Throughput Not so cheap. Competitive with comparatively few cached events. Note: cached events are essentially expired. But much better security 4
Asbestos Latency Lessons from Asbestos Asbestos Latency Lessons from Asbestos Can use VM to protect data in fine-grained way. Performance is respectable, particularly for an unoptimized system. Sometimes high protection is more important than throughput Need to organize apps to keep protected data contiguous and on heap. Otherwise is costly. 5
Recommend
More recommend