User-level Management of Kernel Memory Andreas Haeberlen University of Karlsruhe Karlsruhe, Germany Kevin Elphinstone University of New South Wales Sydney, Australia 1
Motivation: Kernel memory � Kernel memory is needed to implement core abstractions ∼ Files ∼ ∼ � Resource is limited; Threads policy required to control allocation ∼ Address space TCBs Page tables FCBs Kernel Memory pool 2
Motivation: Need for policy while (1) if (!fork()) exit(); gamma login: ahae Password: secret � FCFS is dangerous: bash: fork: Resource temporarily unavailable � Denial of Service uname bash-2.03$ � No isolation bash: fork: Resource temporarily unavailable � Not predictable bash-2.03$ � Need a better policy 3
Motivation: The Perfect Policy � Different scenarios Priorities FCFS Quota require different policies � "Perfect Policy" not known Fair Share Max-min FS Accounting � Solution: Move policy to user level, kernel only provides Working Set Pinning Microecon. mechanism 4
Motivation: Flexibility � Problem 1: Different Web server Video systems have different Efficiency vs requirements Timeliness P P ⇒ Single policy is often a compromise P � Problem 2: Applications Kernel know their future needs better than the kernel DB Sci. comp. Durability ⇒ Suboptimal decisions vs � Solution: Kernel provides Fine-grain P P control mechanism, policy imple- mented at user level P � Used extensively for Kernel normal virtual memory 5
Existing solutions control POLICY POLICY Fixed policy: Linux, L4/Hazelnut Parameters: VS, Resource Cont. POLICY POLICY load/evict control Donation model: L4 Caching model: V++, EROS � Revocation and preemption are not supported 6
The Mechanism Pager Pager k-Pager address Page Page special address App App Kernel Kernel User page fault Kernel page fault 1. Thread touches missing page 1. Thread invokes kernel primitive 2. Kernel catches page fault, 2. Kernel 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 . . . . . . 5. Pager revokes memory 5. Pager revokes memory 7
The Mechanism Kernel memory resources have User K � user-visible names PF map 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 User K � at any time unmap Upon preemption, kernel objects are converted � σ into an external representation Tasks generate faults for preempted objects; � when mapped back, they are fully restored 8
The Vision Real-time system Best-effort system k-Pager App k-Pager Pager k-Pager Pager Kernel Kernel App App App App Support multiple concurrent untrusted managers of kernel memory while preserving Kernel isolation. 9
Maintaining Protection � Before kernel data is exported to user k-Pager level, it is converted into a safe external Byte # C 4711 representation � Safe: Pager cannot use it to gain additional privileges Byte # 4711 TCB � Three broad classes of kernel data: Kernel � Sensitive Page table Kernel stack File pointer (sensitive) (redundant) (safe) � Redundant � Safe 10
Experiment: L4 . . . . . . 5 7 6 IP SP A Regs C B � D Page tables Mapping DB Node tables TCBs vaddr → paddr Mem. alloc. vaddr → mapnode metadata (Redundant) Redundant Sensitive Sensitive/Safe Localized Localized Discarded Localized/Exported (~90%) � Implementation in the L4 microkernel (IA32) � User-level VM and threads, address spaces, IPC 11
Preemption: The kernel stack � Kernel stack can be preempted, but... Kernel TCB switch � ... it is extremely to difficult to parse activation record ext (spill variables) • Global ID xfer • Priority � Idea: Use global • State sys_ stack, continuations • Queues ipc • Space � Global stack can be • ... exc frame preallocated � Additional benefit: Smaller cache footprint 12
Example: Shared Kernel Data C B B � How to export kernel X from A data that describes a A A X to B C relationship between multiple tasks? Kernel Kernel � Re-import requires agreement of all participating tasks A B X to B X from A � Solution: Split data between all tasks, add Kernel mutual references for efficient validation A has given page X to B 13
Evaluation: Performance � Problem: Additional cycles resource checks add 500 485 overhead to IPC 400 � Comparison to 368 L4/Pistachio, both 300 241 kernels unoptimized 200 (preliminary results) 150 � Good performance 100 seems possible � Other benchmarks Pistachio Strawberry Pistachio Strawberry Inter-AS Intra-AS are more interesting, e.g. preemption cost X.2 Ping-pong Benchmark Dual Pentium II/400 KDB disabled, no assertions 14
Evaluation � Experiment 1: Kernel Application User Kernel memory usage on an init 76k 48k L4Linux system bash 392k 52k � Result: Significant part portmap 96k 48k of memory is used for getty 80k 48k kernel metadata inetd 100k 48k � Experiment 2: Cost for smbd 260k 48k kernel PF handling, emacs 2,700k 60k compared to in-kernel memory allocation Allocated 1 fault 18,000 cyc internally � Dual PII/400 system Requested 3 faults 21,400 cyc � Result: ~4µs / fault from pager 15
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
Future Work: Persistence σ 0 σ 0 � Side effect: System can easily be made persistent A D D � By unmapping all memory, σ 0 can B B obtain a snapshot which already is in ext. representation C C 17
Future Work � Develop realistic policies and apply them to realistic scenarios. 18
Recommend
More recommend
