1. Binary Component Adaptation Ralph Keller and Urs Hölzle Dept. of Computer Science University of California, Santa Barbara 1998

2. Motivation • A user should be able to easily integrate binary only code provided by multiple vendors. • It is unrealistic to expect different vendors to code with the same standards. • A single vendor should have a better way to update modules while maintaining binary compatibility between releases. • Problematic with direct source code modification • Currently you only get one chance to “get it right” with an interface.

3. Simple Example

4. Solution

5. The goal of BCA

6. Supported Modifications

7. A replacement example

8. Interface Evolution Example

9. Steps To Using BCA 1. Adaptation FileTextual description of the changes desired. 2. Delta File Adaptation is compiled to a portable delta file containing delta information plus compiled bytecode for new methods. 3. Class File Modification Static: produce new class files Dynamic: modify class files based on available deltas at load time.

10. Delta File Compilation

11. Intermediate class file representation

12. Problems • Naming clashes in “evolved” (distributor modified) versus adapted (user modified) versions. • To solve this every class file needs a record of the version of the module it was compiled against. • If deltas contain renaming, composition order may be relevant. • To be solved by the user.

14. Integration with javac

15. Benchmark Summary • BCA was acceptable fast • The majority of slowdown was due to double parsing of the class file. Could be solved by integration into javac.

16. Conclusions • Allows adaptation of any component without requiring source code access. • Provides a mechanism for release to release binary compatibility. • Robust- can add/rename fields and methods,change inheritance structure, extend interfaces. • Efficient enough to be performed at load time. • This is all good stuff.

17. This Slide Intentionally Left Blank

18. Safe Kernel Programming in the Open Kernel Environment (OKE) Herbert Bos and Bart Samwel Leiden Institute of Advanced Computer Sciences June 2002

19. Goals • Load fully optimized native user code into the kernel. • Use a language OS programmers will be comfortable with. • Allow for various levels of freedom within the kernel depending on user credentials.

20. Predecessors • DrScheme: Support for multiple language access levels. • OKE uses a modified version of Cyclone with the same effect • Spin: Support for user code inside the kernel boundary. Modula-3. Trusted compiler. • Doesn’t handle resource management. Bad code can still consume the memory or cputime. • FLAME: Cyclone + KeyNote + Static checking • Focus on networking code rather than full kernel programability. • Proof Carrying Code(PCC):Uses formal proofs to ensure safety of code. • OKE relies on trust management and language mechanisms instead.

21. OKE & Trust Management • Uses KeyNote and OpenSSL as the foundation. • Public key certification System • “Binds keys directly to the authorization to perform specific tasks.” • Trust chains. Trusted users may delegate trust to others. • “Permission to load a module of type X or type Y, but only under condition Z”

22. Trust Management (cont.) • Types: Rule sets for compiled code. A compiled module will have a signature verifying that it conforms to a given type. • Roles: e.g. “student loading code in kernel” • Types and Roles the responsibility of the administrator to manage.

23. OKE Architecture Framework • The Code Loader • The legislator • The bygwyn compiler

24. The Code Loader • Verifies the integrity of the module and the permission of the user to load the module(based on user credentials). • Otherwise a standard loader.

25. The Legislator • Designed to help automate language customizations for specific tasks while maintaining ‘safety’ in the kernel. • Proof of concept implementation only • “Mechanisms, not policies.” Does not manage any mapping between users and types.

26. The bygwyn Compiler “You can’t always get what you want, but you get what you need.” –Rolling Stones • Allows for a dynamic set of restrictions using the forbid keyword. e.g.: • forbid namespace • Credentials must be supplied to the compiler to determine restrictions. Credentials may differ from CL credentials. • Compiler binds customization types (rule sets) to compiled code with MD5. Generates a signed compilation record.

27. Putting it all together

28. Restricting Cyclone • Untrusted Code must be contained within a single translation unit. • Environmental Setup Code(ESC). • ESC allowed to use inline “C” • Defines external APIs • forbid extern “C” • generates a unique random namespace • No unauthorized imports • No namespace clashes • locked keyword. Allows a struct field to be passed as an argument, but not read or written.

29. Resource Protection • cputime • Timer based(configurable). Generates an uncatchable exception. • Stack Overflow • Static: maximum potential stack usage • Dynamic(for recursion): checks at runtime

30. Region based memory protection • “Outlives” concept derived form Cyclone. • Pointers in one region may only point to data in regions which are guaranteed to outlive the pointer. • Cyclone Heap may point to kernel memory, but not vise versa. • Correct because the kernel will always outlive the module, but problematic since the kernel can free whatever it wants. Tricks required.

31. Wrapping • Calls from kernel to untrusted code are wrapped. • catch Cyclone Exceptions before reaching the kernel. • Free unreleased locks • Calls to kernel functions are wrapped. • Allows insertion of Misbehavior Exceptions • forbid catch • Usually kill a module by throwing an exception. If trying to kill while in the kernel, exception is deferred to the wrapper exit.

33. Applications • Network Monitoring • Packet filters • Traffic analysis • Packet Transcoding • Forward Error Correction (FEC) • Audio packet resampling

34. Open Monitoring Architecture

35. OMA Packet filtering • Prevents access to various parts of the packet • Examples: • Header only • Header only, except for origination access. • Uses const locked fields to achieve this protection at no cost(checked at compile time). • Module acts as a filter with Linux NetFilter hooks (inserted in forwarding path).

36. OMA Packet Transcoding • The packet is removed from the forwarding path. • Traditional solutions require a copy into user memory space. • Example1: Add Forward Error Correction (FEC) to the packet. • Example2: Audio Resampling

37. OMA Packet Transcoding

38. Overhead of Copy to Userspace

39. FEC Overhead- OKE vs. C

40. Overhead of Resampling

41. Other Work:Active Networking and The OKE Corral • Goals similar to that of the Click Modular Router. • Relies on trust management mechanism to allow modules to be loaded into the kernel over a network.

42. Conclusions • The OKE allows optimized modules to be safely integrated into the kernel. • There is a clear performance advantage against both user space implementations (frequently crossing the kernel boundary) and against interpreted solutions such as BPF. In many cases, performance can approach that of native C.