Janos Project: FY 2001
|
|
|
Jay Lepreau |
|
|
|
Flux Research Group |
|
University of Utah |
|
|
|
June 5, 2001 |
The Main Players
|
|
|
Pat Tullmann |
|
|
|
Godmar Back |
|
Mike Hibler |
|
Wilson Hsieh |
|
Rob Ricci |
|
Tim Stack |
Outline
|
|
|
Java OS Work |
|
|
|
Moab / NodeOS API work |
|
Team 3 Demo |
|
ANTS EE |
|
|
|
A Killer Application?! |
|
Failures, Achievements |
Janos Project Goals
|
|
|
|
Resource Control & security of a
local node in an Active Network |
|
First-class, OS-style control over Java
“applications” |
|
Separately useful components |
|
NodeOS, JVM, EE, etc. |
|
Open Source |
Research Goals I
|
|
|
|
Combine OS + Language |
|
Merge OS principles and Java typesafety
to create a real Java OS |
|
Explore which features of Java apply in
an OS context |
|
Explore which OS features map
appropriately into a Java OS |
Research Goals II
|
|
|
|
Apply Java OS to the AN domain |
|
Leverage AN domain’s constraints |
|
Can we safely expose low-level network
aspects? |
|
Can safe code go fast? |
A “Java operating system”
is...
|
|
|
|
An enhanced JVM that provides OS
functions to multiple Java “programs” within it |
|
Features: |
|
Separation |
|
Resource management |
|
Sometimes: direct sharing |
|
Architectural abstractions taken from
OS |
|
User/kernel boundary, processes, etc. |
|
Mechanisms taken from garbage
collection |
Previous Options
|
|
|
|
|
Multiple apps in one JVM |
|
|
|
|
|
One app per JVM in different OS
processes |
“Java Operating System”
|
|
|
+ Good separation |
|
+ Good resource management |
|
+ Allows some direct sharing |
Janos Architecture
Software Specifics
|
|
|
|
Build NodeOS in C that exposes
low-level network features: Moab |
|
Optimized for a single, trusted EE |
|
Provide the NodeOS API in Java: Janos
Java NodeOS |
|
Works with JDK1.x or JanosVM |
|
Provide a JVM for building a Java OS:
JanosVM |
|
Make ANTS multi-domain and
resource-aware: ANTS2.0 |
FY 2001 Progress
|
|
|
Java OS Work |
|
Moab / NodeOS API work |
|
Team 3 Demo |
|
ANTS EE |
|
An Application! |
|
Failures, Achievements |
Java OS Work
|
|
|
|
Ph.D. on Java Operating Systems |
|
Godmar Back - June 12, 2001 |
|
Designed, built and released JanosVM |
|
Evolution of KaffeOS to provide key
building block for a Java OS |
|
Sun JSR-121 Expert Group |
|
“Isolate” : first step in multiprocess
support in Sun’s JDK |
|
Utah representation |
JanosVM
|
|
|
|
Virtual Machine for Java bytecodes |
|
Usual JVM features: JIT, GC, etc. |
|
Multiprocess support |
|
Designed as foundation for Java OS |
|
Exports primitives to build efficient
Java OS |
|
Customized by trusted runtime |
|
|
JanosVM
|
|
|
|
Virtual Machine for Java bytecodes |
|
Usual JVM features: JIT, GC, etc. |
|
Designed as foundation for Java OS |
|
Exports primitives to build efficient,
targeted Java OS |
|
|
JanosVM
|
|
|
|
Virtual Machine for Java bytecodes |
|
Usual JVM features: JIT, GC, etc. |
|
Designed as foundation for Java OS |
|
Exports primitives to build efficient,
targeted Java OS |
|
|
FY 2001 Progress
|
|
|
Java OS Work |
|
Moab / NodeOS API work |
|
Team 3 Demo |
|
ANTS EE |
|
An Application! |
|
Failures, Achievements |
Moab / NodeOS API
|
|
|
|
|
|
Joint NodeOS paper |
|
Pluggable CPU & network schedulers |
|
Click in Moab: fine-grained control
over cut-through channels |
|
More: |
|
NodeOS API refinement, polling vs.
interrupts, SNMP support, filesys support, ... |
FY 2001 Progress
|
|
|
Java OS Work |
|
Moab / NodeOS API work |
|
Team 3 Demo |
|
ANTS EE |
|
An Application! |
|
Failures, Achievements |
Team 3 Demo
|
|
|
|
Built an IP router |
|
in Java |
|
on the Janos Java NodeOS bindings |
|
on JanosVM |
|
on Moab |
|
on the bare hardware |
|
Demonstrated |
|
CPU controls, network bandwidth
controls, and memory controls over Java apps |
|
Inter-operated with 3 other projects |
FY 2001 Progress
|
|
|
Java OS Work |
|
Moab / NodeOS API work |
|
Team 3 Demo |
|
ANTS EE |
|
An Application! |
|
Failures, Achievements |
ANTS EE
|
|
|
|
Completed per-domain separation in
ANTSR |
|
|
|
With UW, evolved and released ANTS2.0
from ANTSR and ANTS1.3, plus: |
|
New security infrastructure |
|
Improved ABONE / ANETD support |
FY 2001 Progress
|
|
|
Java OS Work |
|
Moab / NodeOS API work |
|
Team 3 Demo |
|
ANTS EE |
|
Branching Out |
|
Tangible Goods |
|
Failures, Acheivements |
Branching Out
|
|
|
|
emulab.net - Utah Network Testbed |
|
200 machines, lots of tools |
|
Real users: 70% dist sys, 30%
networking |
|
Developed / tested our Team 3 demo
setup, all our AN experiments |
|
Paper under review |
|
|
|
A killer application?! |
Quote
|
|
|
|
|
“We had a little bit of a problem with
applications.” |
|
|
|
- Sandy Murphy, 4 June 2001 |
Active Protocols for Agile
Censor-Resistant Networks
Key Ideas
|
|
|
Censor-resistant (p2p) publishing is a compelling
and feasible application of active networking |
|
…through on-demand, rapid,
decentralized, diversification of the hop-by-hop protocol (manually, by
people) |
|
|
|
We prototyped this in Freenet |
Active Networking’s Biggest
Problem
|
|
|
Demand: no killer app |
|
|
|
Inherent problem, by definition! |
|
The space of AN protocols is
interesting, not any given protocol |
|
But… a good match for censor-resistant
networks |
Censor-Resistant Networks
|
|
|
|
Goals |
|
Make intentional deletion or denial of
access infeasible or difficult |
|
Often: Anonymity |
|
Usually: overlay network |
|
An example: Freenet |
Some Problems Facing CRNs
|
|
|
|
CRN traffic may be identifiable |
|
Static set of protocols a weakness |
|
Mere membership may be incriminating |
|
Only identification may be necessary,
not eavesdropping |
|
Last link vulnerable: mercy of ISP |
|
Users on restricted networks cannot
participate |
|
But special techniques can get traffic
through firewalls, proxies, etc. |
Agile Protocols
|
|
|
|
Use active networking techniques for
replacement of single-hop protocols |
|
Completely decentralized |
|
Any node (person) can create a new
protocol & pass to its peer |
|
Rapid response time to censorship |
|
Nodes can customize for their
environment |
|
Unbounded set of protocols |
|
Attacker cannot even know what
percentage of set they have discovered |
Protocol Examples
|
|
|
Disguise and tunnel, eg through SMTP,
HTTP |
|
Port-hopping… randomly |
|
Port-smearing (~spread spectrum) |
|
Bounce thru 3rd host |
|
Steganography |
|
…even better in wireless domain:
physical & link level |
What About
Malicious
Protocol Objects?
Protecting Local Node’s
Integrity, Privacy, and Availability
|
|
|
|
Threat model like Java applet, but
worse for privacy |
|
node state: cache contents, neighbor
list, IP addr, username, … |
|
message itself |
|
Integrity and privacy: std type-safety
and namespace isolation |
|
Resource attacks: resource-managing JVM
[OSDI’00, ...] |
Publishing-specific DoS
Attacks
|
|
|
|
|
Same general issues as malicious nodes |
|
Failure (total or intermittent) |
|
Either malicious or unintentional |
|
Heuristic approach: rate Protocol
Objects |
|
Ratings based on success rates for
requests |
|
Evaluate via loopback test harness |
|
Ratings are node-local |
|
More attacks/responses in paper |
What About Bootstrapping?
|
|
|
Shared by base Freenet system: must
acquire initial {IP addr, port} out-of-band |
|
Now need {IP addr, byte code} |
|
Quantitative difference ==>
qualitative change? |
|
Memory, piece of paper ==> floppy
disk, email attachment, applet |
|
Conclusion: acceptable |
Our Implementation
|
|
|
Prototype based on Freenet system |
|
Peers can exchange Java bytecode for
new protocols |
|
Protocol usage can be asymmetric, can
change on any message boundary |
|
Restricted namespace |
Four sample Protocol Objects
|
|
|
‘Classic’ Freenet protocol |
|
HTTPProtocol: Looks (vaguely) like HTTP |
|
TrickyProtocol: Negotiates port change
after every message |
|
SpreadProtocol: Splits message on
arbitrary byte boundaries, sends each chunk on a different port |
Reprise:AN’s Major Technical
Challenges
|
|
|
|
Performance: no problem |
|
In Java already! |
|
Overlay network: IP not my problem |
|
Security |
|
Key: change local, keep global protocol |
|
Global network: domain-specific,
therefore tractable. |
|
Local to node: tractable, based on recent research |
Agile Experiment:
Conclusions
|
|
|
|
AN techniques seem likely to improve
the censor-resistance of such networks |
|
Feasible to implement in existing
systems |
|
Lots still to do |
|
Implement ratings, etc, etc |
|
JanosVM + runtime, re-engineer base |
|
Evaluate in the lab |
|
Evaluate “in the wild” |
|
Lot of fun, lot of military relevance |
FY 2001 Progress
|
|
|
Java OS Work |
|
Moab / NodeOS API work |
|
Team 3 Demo |
|
ANTS EE |
|
Tangible Goods |
|
Failures, Achievements |
|
|
Papers: FY 2001
|
|
|
Back et. al. Processes in KaffeOS: Isolation, Resource Management and
Sharing in Java (OSDI 2000) |
|
|
|
Tullmann et. al. Janos: A Java-oriented OS for Active
Network Nodes (IEEE JSAC Mar 2001) |
|
|
|
Peterson et. al. An OS Interface for Active Routers |
|
(IEEE JSAC Mar 2001) |
|
|
|
Ricci et. al. Active Protocols for Agile Censor-Resistant Networks (HotOS 2001) |
Software Releases: FY 2001
|
|
|
|
11 separate releases |
|
2 OSKit versions |
|
2 Moab versions |
|
2 JanosVM versions |
|
1 ANTS2.0 |
|
2 Java NodeOS versions |
|
1 ANTS CVS |
|
1 Java NodeOS CVS |
Mistakes I
|
|
|
|
Over-emphasis on strict hierarchy |
|
Original nested process model |
|
NodeOS mempools |
|
NodeOS/EE split |
|
Makes a nearly impossible research
challenge even harder |
|
Under-emphasis on applications |
Mistakes II
|
|
|
|
Too much energy on software artifacts |
|
==> Missed research opportunities |
|
ANTS? |
|
Most aggressive AN model |
|
Dated |
Mistakes III
|
|
|
|
|
A-Flow -> Flow -> Domain |
|
|
|
Failure to keep dm in ITO! |
Achievements
|
|
|
|
Four generations of Java OS’s |
|
Culminated in generic JavaOS
infrastructure |
|
Java spec impact: JSR-121 “Isolate”, ... |
|
Low-level networking that leverages
type-safety |
|
Safe zero-copy |
|
Unoptimized Java IP forwarding is
40% speed of C (JNodeOS v. Moab) |
|
|
Questions?
|
|
|
|
|
|
Where do I get Janos papers, software? |
|
www.cs.utah.edu/flux/janos |
|
|
|
How do I use the network testbed? |
|
www.emulab.net |
END OF PRESENTATION
Architecture
Approach
|
|
|
|
Re-fit existing AN infrastructure to
multiprocess, resource-aware JVM |
|
Apply OS principles to Java language
run-time |
|
User/kernel boundary, processes, etc. |
|
Construct a “multiprocess” JVM |
|
Build a NodeOS that exposes low-level
network features |
Team 3 Demo
|
|
|
First full Janos prototype to run Java
on the bare hardware |
|
Illuminated many performance issues in
our prototype |