Powerpoint - School of Computing
Download
Report
Transcript Powerpoint - School of Computing
Processes in KaffeOS:
Isolation, Resource Management,
and Sharing in Java
Godmar Back
Wilson Hsieh
Jay Lepreau
School of Computing
University of Utah
School of Computing
Janos Project
Motivation
Java Applications
– Untrusted code: possibly malicious or buggy
– Multiple applications on behalf of multiple users
Efficient use of resources
– Resource-constrained environments: “small” systems
(handhelds, embedded systems)
– Increased scalability
School of Computing
2
What is KaffeOS
A Java operating system:
– Enhanced JVM that provides operating system functionality
Features:
– Separation
– Resource management
– Direct sharing
Focus on memory (GC) and CPU management
Architectural concepts taken from OS
Mechanisms taken from garbage collection
School of Computing
3
Current Options
-
Multiple apps in
one JVM
App1
App2
App3
JVM
Base OS
-
One app per
JVM in different
OS processes
App1
App2
App3
JVM
JVM
JVM
Base OS
School of Computing
4
Java Operating System
App1
App2
App3
App4
Java OS
Base OS
+ Good separation
+ Good resource management
+ Allows some direct sharing
School of Computing
5
KaffeOS Design Principles
Process separation
Full reclamation of memory
Precise memory and CPU accounting
Direct sharing
Safe termination of processes
Hierarchical memory management
School of Computing
6
Process Separation
Protecting access to a process’s objects
– Via Java type safety, via Java name spaces
Define a user/kernel boundary
– Protect integrity of kernel
– Guarantee safe termination [HotOS ’99]
Separation of resources
– Memory, CPU, garbage collection
School of Computing
7
Heap Structure (user heaps)
user heap
user heap
user heap
kernel heap
School of Computing
8
Full Reclamation
Assumption: do not have MMU to unmap memory
– Rely on garbage collection to free objects
References can make objects unreclaimable
– Define and enforce set of rules for writes that create references
Define heap structure
School of Computing
9
Heap Structure (user heaps)
X
user heap
user heap
user heap
kernel heap
School of Computing
10
Enforcing Heap Structure
Certain cross-heap pointers are illegal
– User-user pointers are illegal
Use GC “write barrier” to enforce
– Check heaps on every write
– Throw SegmentationViolationError if illegal
Small cost on legal write (common case)
– Microbenchmarks (tight loop, hot cache)
» 41 cycles without memory overhead
» 25 cycles with slight memory overhead
School of Computing
11
Memory and CPU Accounting
Accurate and complete per-process accounting
– Minimize number of objects on kernel heap
– Minimize amount of time spent in kernel code
Separate garbage collection
– Minimize unaccounted resource use
– Avoid priority inversion
– Maintain isolation
School of Computing
12
Heap Structure (separate GC)
user heap
user heap
user heap
xv
e
School of Computing
kernel heap
13
Heap Structure (resolving cycles)
user heap
user heap
user heap
user heap
user heap
kernel heap
School of Computing
14
Direct Sharing
As Interprocess Communication Mechanism
Objects may contain pointers to other objects
– Preserve Java model
Accounting of shared objects
– Sharers are all charged for shared heaps: double charging
– Non-double charging does not work
Reclamation
– As soon as garbage collector detects that nothing on shared heap
is referenced
School of Computing
15
Heap Structure (shared heaps)
user heap
user heap
user heap
X
shared heap
shared heap
kernel heap
School of Computing
16
Performance Results
Overhead for well-behaved applications
– SpecJVM98 benchmarks: 2-8%
Comparing
– IBM JDK 1.1.8
– Base JVM: Kaffe (www.kaffe.org)
» Current version: Kaffe00 (June 2000)
– KaffeOS with unoptimized write barrier
– KaffeOS with optimized write barrier (memory overhead)
School of Computing
17
SpecJVM Performance of KaffeOS
70
KaffeOS
KaffeOS
unoptimized WB optimized WB
GC Time
60
Kaffe00
Run Time
Seconds
50
40
IBM JDK1.1.8
30
20
10
0
compress
School of Computing
jess
db
javac
mpegaudio
mtrt
jack
18
MemHog DoS Scenario
Off-the-shelf Servlet engine
– Linux 2.2.x w/ 256MB, Apache 1.3.12, JServ 1.1, JSDK 2.0
How would we deal with this?
– Run 1 servlet per IBM JVM (IBM/1)
– Run all servlets on one IBM JVM (IBM/n)
– Run each servlet in a KaffeOS process
IBM/1
IBM/N
KaffeOS
IBM/1, MemHog
IBM/N, MemHog
KaffeOS, MemHog
School of Computing
19
Service Under DoS Attack
10000
IBM/1
IBM/n
KaffeOS
IBM/1,MemHog
IBM/n,MemHog
1000
Seconds
KaffeOS,MemHog
100
10
1
0
10
20
30
40
50
60
70
80
Servlets
School of Computing
20
Related Work
Other Java Operating Systems
– J-Kernel/JRes [Hawblitzel ’98, Czajkowski ‘98],
Alta [Tullmann ‘99], Java Nucleus [van Doorn ’00]
Java VM extensions
– Multiprocess JVM [Balfanz ‘98], IBM [Dillenberger ‘00], Oracle 8i
Java language extensions
– Luna [Hawblitzel]
– Java Realtime Extensions [Sun ‘00]
Operating Systems
– Opal [Chase ‘94]
– Pilot [Redell et al. ‘80], Cedar [Swineheart et al. ‘86],
– Spin [Bershad ‘95], Inferno [Dorward et al. ‘97]
School of Computing
21
Ongoing Work & Open Issues
Running other DoS attacks
– GarbageHog: allocate and abandon lots of memory
– CPUHog: execute for too long
Create bigger applications that use direct sharing
model for IPC
Demonstrate safe termination claim experimentally
School of Computing
22
Summary
Java operating systems are necessary to support
untrusted Java applications efficiently
KaffeOS
– Architectural concepts taken from operating systems
– Mechanisms taken from garbage collection
» Distributed GC
» Write barriers
Big issue: dealing with memory/GC
Resource-based denial-of-service attacks can be
stopped
School of Computing
23