"The Open Kernel Environment"

[ 06/03/04 While active development on this project has ceased, apparently there is still external interest in the OKE: it recently featured on Computer Science Daily. ]

The Open Kernel Environment

The open kernel environment (OKE) allows users other than root to load native and fully optimised code in the kernel. This web page is only meant as a brief introduction to the OKE. More information can be found in the various publications. To obtain (a pre-release of) the OKE check out the OKE release page , where some of the quirks, requirements and steps are explained that you will need to know to get it up and running. On this and related pages, you can find the following:

	An overview of the system.
	Some thoughts about the application area.
	A description of how the OKE was used in building an active node (combining it with the Corral, a system similar to the Click software router).
	A recent approach of pushing the OKE to the level of network processors.
	The OKE release page.
	The latest documentation (includes users' guide, installation instructions, configuration guide).
	List of OKE publications.

OKE Overview

The open kernel environment (OKE) allows users other than root to load native and fully optimised code in the kernel. Loading code in the kernel is a highly privileged operation. Normally, a modern operating system (OS) allows only root-users to do so. Allowing third-party code into the kernel jeopardises all security constraints, as the code can `do anything'. For untrusted code this is not acceptable. From a performance perspective, on the other hand, it would be useful. For example, time-critical network applications, such as transcoders, monitors and filters, want to avoid crossing the kernel-userspace boundary for every packet, because of the overhead. Instead of relegating flows of packets to userspace for processing, one would rather do as much processing as possible in the kernel and send only the results to the application. Moreover, one would rather use fully optimised native code than an interpreted filter language such as used by BSD packet filters.

In the OKE instead of asking whether or not a party may load code in the kernel we ask: what is such code allowed to do there? Trust management is used to determine the privileges of user and code, both at compile time and at load time. Based on these privileges a trusted compiler may enforce extra constraints on the code (over and above those imposed by the normal language rules). This means that, in stark contrast with approaches such as Java (and many others), the amount of restriction depends on your privileges, so that, for instance, a student's code is very heavily policed, while a system's programmer's module is only restricted in a minimal way (or not at all).

This is illustrated in the top half of Figure 1. The Bygwyn compiler applies extra rules (restrictions) to the compilation of a user's code, based on the credentials this user is able to present. As a result, the generated code, may incur dynamic checks for safety properties that cannot be checked statically. After comilation, the module is 'safe' with respect to the security constraints imposed by the extra rules. For example, it may guarantee that the code: will not use up too much CPU time or memory, will not crash the kernel, can only access certain kernel functions and certain bits of memory, etc.

Figure 1. A user compiles and loads code in the OKE

In other words, we have code restriction based on the programmers' privileges (as determined by their credentials). The compiler generates object code with the appropriate restrictions, as well as a (signed) record specifying what type of restriction applies to this code. However, at this point nothing is said about who is allowed to load this module. This is a separate policy, as illustrate in the bottom half of Figure 1. The user (who may be different from the programmer who compiled the code) offers code and credentials to a code loader (CL). The CL checks both code and credentials against its security policies, and if they match, loads the kernel module. The OKE guarantees that the module complies with the rules that were set for it. If the module misbehaves in any way, it is automatically unloaded.

OKE Applications

The OKE provides mechanisms rather than policies. Application areas may vary widely. For example, in an academic environment, the OKE could be used in a course on kernel programming. System and low-level network programmers may use the OKE to test new code in a safe environment (possibly progressively removing restrictions as the code becomes more robust over time). Potentially more interesting application areas, however, are those of network monitoring, charging, filtering, traffic shaping and transcoding. Such applications all require high-speed processing so that implementation in user space is often not feasible. Currently it is difficult for network operators to add such functionality to their networks, especially if the code is provided by different departments/business-units, or worse still, competitors. The publications below describe how we implemented filtering and transcoding architectures for the open kernel environment and discuss their performance.

The OKE system may also be used to extend (at runtime) the functionality of specific kernel component. E.g. for a specific user, it may extend the file system in such a way that all files that are written to disk are first compressed.

OKE Corral

The safety properties and resource control offered by the OKE were used to build the OKE Corral, an active network environment which allows third-party active code to control the code organisation at any level of the network node. This includes the kernel. The underlying code is structured much like components in a 'Click'-router that may be connected or disconnected at runtime. Using this, active packets are able to reconfigure predefined components in the networking code, regardless of their location. Moreover, using the safe programming model of the open kernel environment, they are able to load and link their own components at any place in the datapath and at any level in the packet processing hierarchy.

In the OKE Corral project three novel technologies in the field of networking and open systems (open kernels, the `Click software router' model and active networks) are combined to provide a platform for fast programmable packet processing with explicit separation between control and data flow. In the system, high-speed packet processing can be conveniently managed by slow-speed control code. The essence can be summed up as follows:

(1) We borrow the LEGO-like software organisation model that was advocated by the 'Click' router project at MIT both to build fast data-paths and to implement paths for control traffic. Instead of using the Click directly, we implemented our own software for this purpose which is different from Click in that it provides explicit support for elements that reside in different domains (e.g. kernel, user space, remote machines, etc.).

(2) One of the components on the control path is an active network runtime (if required, this path can also be used for data packets, but because the control path is fairly slow, this is much less efficient).

(3) The configuration and implementation of the other control and data path components can be initiated by active packets, remote parties, or both.

(4) The OKE is used to ensure that kernel-level implementations of the path components are safe.

In the Corral the `active code' running in the active network runtime plays the role of control and management software and operates at a much slower speed than the fully compiled code in the data-path. Both the control and the data plane use the same OKE channel mechanism to construct their flows. The performance of the OKE Corral varies with the amount of programmability. At one extreme, only the control and management is programmable, while the data-path consists of predefined and highly optimised `standard' components based on which custom data-paths can be constructed. At the other extreme, there is the `capsule' approach advocated in some other active network projects. Between these two extremes, but closer to the former extreme, we have the OKE channels approach. For maximum flexibility, the different kinds of programmability may be mixed and matched, so that `capsules', pre-defined and third-party components all interact to build data and control flows. Open issues include the problem of heterogeneity, as well that of trust propagation. These are the topics of ongoing research.

HOKES/POKES: OKE on network processors

More recently, we have pushed the OKE concepts to even lower levels in the processing hierarchy: the network processor. In our implementation the OKE consists of two parts:

(1) The OKE in the Linux kernel on a host-like system such a Pentium general purpose processor: HOKES (host-like OKE System)

(2) The OKE on an embedded system (e.g. a network processor) that runs no operating system whatsoever: POKES (Peripheral OKE System).

In the current implementation. HOKES provides all the required OKE mechanisms for safe code loading in the Linux Kernel on an x86 platform. POKES offers a similar approach, but somewhat different mechanisms for the microengines of an Intel IXP1200 network processor. For examples, while HOKES must guard against CPU usage violations, a microengine in the network processr is assumed to be dedicated to a an application (i.e., not shared). In other words, this is not a shared resource and hence there is no need to limit an application's processing time on the microengine. On the other hand, a network processor is designed to handle packets at link speed, which meand there is, on average, only a limited cycle budget per packet. So now the processing time limitation is posed not in terms of restricting the usage of processing units, but in terms of whether an application has processed its packets within the availabke cycle budget.

Publications

	HOKES/POKES: Lightweight Resource Sharing . (Proceedings of 3rd International Conference on Embedded Software, EMSOFT'03, Philadelphia, PA., USA, October 2003.) [PDF version]
	Safe Execution of Untrusted Applications on Embedded Network Processors . (to appear in "Domain-Specific Processors: Systems, Architectures, Modeling, and Simulation", by Marcel Dekker, Inc., December 2002.) [PDF version] Here is a comprehensive two-column version that does not require so many pages as the orginal format. [PDF version]
	The OKE Corral: Code Organisation and Reconfiguration at Runtime using Active Linking (Proceedings of IWAN'2002, Zuerich, December 2002). [PDF version] An extended version of this paper was published as Technical Report: High Noon at the OKE Corral: Code Organisation and Reconfiguration at Runtime using Active Linking . (Technical Report, June 2002) [PDF version]
	Safe Kernel Programming in the OKE . (Proceedings of OpenArch'2002, New York, June, 2002) [PDF version]
	The Open Kernel Environment. (OpenSig'2001, London, September, 2001)

People

	Herbert Bos (email)
	Bart Samwel (email)

[ Herbert Bos ]