|home search contact|
"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:
OKE OverviewThe 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.
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.
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.
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 processorsMore 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.
|[ Herbert Bos ]|