Virtual Memory Management in Mach n Labels and

Virtual Memory Management in Mach n Labels and Event Processes in Asbestos n Ingar Arntzen

Introduction n Virtual Memory ¡ Decoupling processes and physical address space Virtual address n Physical address Two problems – One solution ¡ Memory Management n ¡ Process footprint grows to fill available memory Isolation & Protection n Mapping Function Processes need to be isolated from other Processes Resources need to be protected from Processes Papers: Focus on different issues

Memory Management n Problem: Not enough main memory ¡ n Copy data between main memory and disk Virtual Memory / Paging ¡ ¡ ¡ Need only parts of process to execute Process footprint -> pages On demand pagein x n Page table ¡ ¡ One entry per virtual page X: Absent Virtual address Main Memory x x MMU Physical address

Importance n Memory Management & CPU Utilization ¡ ¡ Interleave i/o-bound processes Effective MM => more processes may run concurrently n n Decrease probability that all block at the same time Future ¡ Processes will continue to fight for physical memory

Isolation & Protection n Isolate processes from each other ¡ n Mapping : Process address-spaces map into disjunct physical address-spaces Resource protection ¡ Mapping : References protected by access control bits. Referenced Modified Present/Absent Page frame # Protection

Research n Tradeoff pagesize ¡ Too small n ¡ Too big n ¡ n huge pagetable, frequent page faults Less concurrency, costly pagein 0, 5 – 64 KB Page Replacement Algorithms ¡ NRU, FIFO, CLOCK, LRU, …

Research cont. n Effective Pagetable implementation ¡ Huge pagetable n ¡ Pagesize 4 KB, 32 -bit address space => 1 M entries Fast pagetable lookup n Evaluated on every memory reference ¡ n More than 1 memory reference per instruction Design options ¡ Hardware registers n ¡ Main memory n ¡ + fast, - expensive, - context-switch penalty + cheap, - extra memory ref, - steals precious memory Something in between

Research cont. n Optimizations ¡ Multilevel pagetable n ¡ Cashing Pagetable-entries in hardware n ¡ TLB exploits locality. Very effective! Inverted Page table n n ¡ Pageout unused parts (physical page frame -> virtual page) + Smaller, - Expensive to search Software control of hardware n TLB cashe management, pagefault handling

Research cont. n Result ¡ ¡ ¡ Multitude of hardware solutions Multitude of software designs Discussions n n What are the best solutions? Where to draw the line between HW and SW? User-level meddling in HW business? => Context of paper 1

Virtual MM in Mach n Problem ¡ Portability n n Strong dependencies between HW and OS Mach goals ¡ Virtual Memory Management n …on top of diverse HW architectures ¡ ¡ n Few HW assumptions Clean HW/SW separation Easy to port No performance loss Approach ¡ Experiences with building and porting Mach

Mach Virtual Memory n n Microkernel OS Integrated Message Passing and Virtual Memory ¡ n Send = memory remap (cheap!) Threads may… n n Allocate, de-allocate virtual memory Share address spaces Copy address spaces Pagein and pageout

Implementation n Address Map (Page. Table) ¡ Ordered, linked list or refs to Memory Objects (E. g. files) n n + Only entries for used addresses - More searching Address Map (Page Table) n Memory Object List Pagefault handling ¡ User level Pager Services n Message Passing between Kernel and Pager Main Memory

Evaluation n Ported to ¡ ¡ n Clean separation ¡ n But may be used by Mach Performance ¡ ¡ n HW dependent and HW independent TLB not required ¡ n VAX, IBM RT PC, SUN 3, … Unix. PT, Inverted. PT, PT/Segment Comparison UNIX - Mach on different architectures Mach equal or better Conclusion ¡ Clean separation is possible and has no cost!

Labels and Event Processes n Isolation and Protection in Web. Services ¡ ¡ n Stateful services with many concurrent users Isolation between users (not processes) Goals ¡ ¡ Execute user requests in isolated address spaces Restrict information flow n n Avoid leaking private user data User data only communicated to privileged system parts Principle of least privilege Application specific policies

Labels n Basic Idea ¡ Restrict access to communication primitives, send & recv n n n A can talk to B, if B is equally privileged If B receives a message from A, this may restrict B’s ability to speak with others Labels define send & recv privileges relative to domains (compartments) ¡ Kernel support n ¡ operations + checking of privileges Applications define information flow policies

Event Processes n n Execute user requests in isolated address spaces? Problem ¡ ¡ Address spaces are associated with processes Forking 1 process per user does not scale! n ¡ n One reason: Huge pagetables Threads scale better, but provide no isolation Solution ¡ ¡ Isolate data from multiple users within one address space Event Process Abstraction n Event handler executes in the context of a given user

Implementation n Base Process ¡ ¡ Address space divided between event processes Event processes n Context ¡ ¡ ¡ n n Receive Ports Communication privileges (Labels) Private user data Bind to private ports Scheduled by kernel within private context ¡ (On incoming message)

Evaluation n Experiments on Web. Service ¡ Memory consumption n ¡ Extra 1. 5 Page (4 KB) per event process! Cost of Isolation (Labels) n n Modest overheads on throughput, latency Throughput decrease as with increasing number of event processes ¡ n Database costs due to label storage growth Importance ¡ ¡ Virtual address is to big How do we implement small virtual address spaces for lightweigth processes?