Janos A Java-oriented Active Network Operating System

1. JanosA Java-oriented Active NetworkOperating System Jay Lepreau, Patrick Tullmann, Kristin Wright Wilson Hsieh, Godmar Back, many more... University of Utah Flux Research Group www.cs.utah.edu/flux/ March 30, 1999

2. Goals • Develop a principled yet efficient local OS architecture for active nodes, oriented to hierarchical structure, resource control, and security. • Produce separately useful OS, security, and Java VM components.

3. Goals 2 • Investigate local resource management and security in language-based systems • Java, in particular • Investigate OS support for active networking • Investigate broader resource management issues

4. Memory CPU Network bandwidth Resources (obvious)

5. Resources (less obvious) • Backing/caching store • Persistent store • Encryption hardware • Other specialized hardware… • DSPsl • Reconfigurable HW? • Special links (eg long set up time) • Specialized data... • Routing table entries? • ...

6. Genesis • Builds on three lines of existing work: • Fluke Nested Process Model • Strong OS model with a new protection mechanism: focus on resource control • Flask security architecture • Policy-flexible fine-grain mechanisms • The OSKit • Reusable low-level components and a framework (COM, APIs) • Other: • Optimization of Java for systems code • predictability, speed • Network testbed (possibly)

7. Janos Structure AN Execution Environment Janos VM The OSKit Hardware or Unix

8. Primary Execution Environment • Java-based • Prototype will be based on ANTS [Wetherall et al. 97] • Initial changes to ANTS structure and execution model to better support resource control (released June ‘98) • Integration with Janos resource management • Admission control • Prevent denial of service • Fair sharing

9. The Nested Process Model Child process is encapsulated in its parent. Traditional Process Model Nested Process Model Parent Process State Parent Process State Child State Child State Child State Child State Parent has complete control over the child.

10. Parent Process State Parent Process State Child State Child State Child State Child State Nested Process Model • Derived from a recursive virtual machine model • Resources for a process are obtained from parent • Parent services requests for new resources and for management • Strict hierarchy enabled, not enforced Traditional Fluke

11. Fluke: microkernel and server implementation of OS model Flask: high-security version of Fluke Alta: Fluke architecture implemented in a JVM, using type-safety for memory protection Obscure Names

12. Swap in Patrick

13. Joint with NSA R23, SCC Security architecture orthogonal to Flask implementation Augments Fluke with fine grained security mechanisms Explicit security bindings Mandatory controls Mutual authentication Flask: High-security version of Fluke

14. Policy flexibility: Dynamic both in time and in configuration Economic and market reasons Separate security policy “decider” makes all policy decisions Revocation support Investigating extensions to multiple policy servers Flask: Security Policy

15. The OSKit

16. Dual Execution Modes

17. User Friendly OS Development ….!?

18. Example Working Kernel #include <stdio.h> main() { printf("Hello, world.\n"); return 0; }

19. Major releases 18 Dec 98, 15 Jan 99 Unique downloads running 1000/month 600 on mailing list Base for Janos prototype on bare hardware Another route for Utah/NSA security tech xfer Likely vehicle for external OS research tech xfer (Quorum, NT) Evolving into flexible OS itself OSKit Status

20. Make components more separable Dynamic loading and linking Module configuration language & GUI “Protection” component Further integrate with languages Java Scheme (Indiana, Kansas, Rice) ML (MIT, CMU) …. OSKit: Ongoing and Future

21. Buffering/caching (IO-Lite?), network mgmt protocols, ... Modular protocol impl. Secure boot (Penn), filesys (Linux xfer), policy engine Network components access checks at all levels and objects (local node, remote node, interface, routing table, …) Crypto, auth, PCC verifier (w/ CMU/Cedilla) …. OSKit future components

22. Threads schedule each other by donating the CPU using a directed yield primitive One root scheduler per processor sources all CPU time Kernel dispatcher manages threads, events, and CPU donation without making any scheduling policy decisions CPU Inheritance Scheduling

23. Stride (WFQ) Scheduling 600 400 50 50 60 % CPU 20 % CPU 20 % CPU

24. Possible Curves in the Road • Fluke model will likely be modified • Hardware protection may be included • Flask security architecture may not map well to Java and Janos • Challenges in GC and cpu interactions. • More surprises undoubtedly await…

25. The Big Todo • GVM and Alta prototypes: evaluate, choose best pieces, synthesize • Evaluate use of hardware protection in the OSKit • Refine and integrate AN execution environment • Measure and tune performance • Leverage AN-specifc fine-grained sharing

26. Summary • Resource control and security in Java • Applicable in other language-based systems • Explore power/speed of software mechanisms • Primary motivation: active networks and other mobile code • Useful in other contexts • Servlet environments • Active service environments • OS without hardware protection • Wide applicability and tech xfer thru the OSKit • www.cs.utah.edu/flux/