User-level Management of Kernel Memory

Transcription

1 User-level Management of Memory Andreas Haeberlen University of Karlsruhe Karlsruhe, Germany Kevin Elphinstone University of New South Wales Sydney, Australia 1

2 Motivation: memory Threads Files memory is needed to implement core abstractions Resource is limited; policy required to control allocation Address space TCBs Page tables FCBs Memory pool 2

3 Motivation: Need for policy while (1) if (!fork()) exit(); gamma login: ahae Password: secret bash: fork: Resource temporarily unavailable bash-2.03$ uname bash: fork: Resource temporarily unavailable bash-2.03$ FCFS is dangerous: Denial of Service No isolation Not predictable Need a better policy 3

4 Motivation: The Perfect Policy FCFS Quota Priorities Different scenarios require different policies Fair Share Max-min FS Accounting "Perfect Policy" not known Working Set Pinning Microecon. Solution: Move policy to user level, kernel only provides mechanism 4

5 Efficiency vs Timeliness Durability vs Fine-grain control Motivation: Flexibility Web server P Sci. comp. P P P Video P DB P Problem 1: Different systems have different requirements Single policy is often a compromise Problem 2: Applications know their future needs better than the kernel Suboptimal decisions Solution: provides mechanism, policy implemented at user level Used extensively for normal virtual memory 5

6 Existing solutions control POLICY Fixed policy: Linux, L4/Hazelnut POLICY Parameters: VS, Resource Cont. POLICY POLICY control load/evict Caching model: V++, EROS Donation model: L4 Revocation and preemption are not supported 6

7 The Mechanism Pager Pager k-pager Page address Page special address App App User page fault page fault 1. Thread touches missing page 1. Thread invokes kernel primitive 2. catches page fault, 2. detects missing metadata, blocks thread, notifies pager blocks thread, notifies pager 3. Pager allocates memory 3. Pager allocates memory 4. Thread is resumed 4. Thread is resumed Pager revokes memory 5. Pager revokes memory 7

8 The Mechanism memory resources have user-visible names Tasks send page fault messages to request additional kernel memory Manager responds by mapping ordinary memory to the task Memory that is being used by the kernel is not accessible from user level All kernel memory can be preempted at any time Upon preemption, kernel objects are converted into an external representation Tasks generate faults for preempted objects; when mapped back, they are fully restored User User PF σ σ K map K unmap 8

9 The Vision Best-effort system Real-time system App k-pager k-pager Pager k-pager Pager App App App App Support multiple concurrent untrusted managers of kernel memory while preserving isolation. 9

10 Maintaining Protection C TCB stack (sensitive) Page table (redundant) k-pager Byte # 4711 Byte # 4711 File pointer (safe) Before kernel data is exported to user level, it is converted into a safe external representation Safe: Pager cannot use it to gain additional privileges Three broad classes of kernel data: Sensitive Redundant Safe 10

11 Experiment: L A B C... IP SP Regs D Page tables vaddr paddr Mapping DB Mem. alloc. Node tables vaddr mapnode TCBs metadata Redundant (Redundant) Sensitive Sensitive/Safe Discarded Localized Localized Localized/Exported (~90%) Implementation in the L4 microkernel (IA32) User-level VM and threads, address spaces, IPC 11

12 Preemption: The kernel stack TCB stack can be preempted, but... Global ID Priority State Queues Space... activation record switch to ext xfer sys_ ipc exc frame... it is extremely difficult to parse (spill variables) Idea: Use global stack, continuations Global stack can be preallocated Additional benefit: Smaller cache footprint 12

13 Example: Shared Data A B X to BC A X to B B A B X from A A has given page X to B C X from A How to export kernel data that describes a relationship between multiple tasks? Re-import requires agreement of all participating tasks Solution: Split data between all tasks, add mutual references for efficient validation 13

14 Evaluation: Performance cycles Pistachio Strawberry Inter-AS 241 X.2 Ping-pong Benchmark Dual Pentium II/400 KDB disabled, no assertions 150 Pistachio Strawberry Intra-AS Problem: Additional resource checks add overhead to IPC Comparison to L4/Pistachio, both kernels unoptimized (preliminary results) Good performance seems possible Other benchmarks are more interesting, e.g. preemption cost 14

15 Evaluation Application init bash portmap getty inetd smbd emacs Allocated internally Requested from pager User 76k 392k 96k 80k 100k 260k 2,700k 1 fault 3 faults 48k 52k 48k 48k 48k 48k 60k 18,000 cyc 21,400 cyc Experiment 1: memory usage on an L4Linux system Result: Significant part of memory is used for kernel metadata Experiment 2: Cost for kernel PF handling, compared to in-kernel memory allocation Dual PII/400 system Result: ~4µs / fault 15

16 Conclusions Good kernel memory management is important for security and performance The proposed mechanism allows multiple concurrent user-level policies and supports preemption The mechanism requires additional page faults, but they are not expensive 16

17 Future Work: Persistence A B C σ 0 D Side effect: System can easily be made persistent By unmapping all memory, σ 0 can obtain a snapshot which already is in ext. representation 17

18 Future Work Develop realistic policies and apply them to realistic scenarios. 18