Binary Component Adaptation

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.

13
(No Transcript)
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.
• Doesnt 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 cant 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.

32
(No Transcript)
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 WorkActive 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.