Kernel Mode Database

At the heart of many operating systems is the kernel.

Many times, there is no boundary between the operating system and the tasks that carry out the primary purpose of the system, e.g. an industrial controller. In other words, the operating system and the tasks all operate in the same address space. This is in contrast to multi-tasking operating systems like Linux, Windows, et. al., that have distinct kernel space and user space wherein the operating system and each process have their own virtual address space and are protected from each other.

To accelerate overall system performance, some applications are deployed, entirely or in part, as kernel mode software components. Often such kernel-based software must sort, store and retrieve complex data – for example, an access control system’s “policy engine” may reside in the kernel and need to check a rules database to determine whether a process has permission to open specific files in a certain mode and at a certain time and date.  They can be responsible for resource allocation, scheduling, low-level hardware interfaces, network, security and other integral tasks.

No room for error

When everything shares a common address space, it puts a premium on code quality because an error in any one task will compromise the integrity of the entire system, not just that task. You can read about a key way in which this concern was addressed by the creators of eXtremeDB, here.

Software that is written to execute as a kernel task in a multi-tasking operating system has the same concern. The most common examples are device drivers. These are bits of software that run within the operating system’s kernel space, but that are not supplied by the operating system itself. A defect in a device driver is likely to crash the entire system.

Certain types of application software lend themselves to having a portion of their functionality implemented in kernel space, and need access to a large repository of information (aka a database). For example, an access control/user authentication system that allows you to create rules like “Susan can open/read/write file XYZ from 9AM to 5PM weekdays.” Ideally, the control panel for this application would run in user space for easy setup of the rules, and the rule-checking module would run in kernel mode because file operations should be very fast and not require extra context switches between user space and kernel space. Therefore, a database system that can be used by both kernel tasks and user-space applications is needed. eXtremeDB Kernel Mode (KM) is such a database that can be used with the confidence that it won’t compromise the integrity of the operating system.

The first kernel mode database system

eXtremeDB Kernel Mode is the first database management system (DBMS) designed explicitly to run in the OS kernel, providing kernel-based application functions with critical database capabilities such as transaction processing, querying using multiple index types, multi-threaded data access, a flexible database API, and a high-level data definition language.

McObject pioneered in-memory embedded databases with its ultra-small footprint eXtremeDB. eXtremeDB’s efficiency, and its streamlined, all-in-memory architecture, permit its deployment in the kernel, where other database management systems (DBMSs) might overwhelm kernel resources.

In representative applications, eXtremeDB-KM performed an order of magnitude faster than the alternative of deploying a database system in user space and requiring kernel processes to access it via expensive (in performance terms) context switches.

Direct access to kernel data

eXtremeDB-KM is an in-memory database system that provides direct data access to kernel processes. The eXtremeDB run-time maps its databases into the driver or kernel module address space, providing pointers to the data elements and eliminating expensive buffer management.

The eXtremeDB-KM run-time code is directly linked with the module, so remote procedure calls are eliminated from the execution path. As a consequence, the execution path generally requires just a few CPU instructions. Kernel-mode threads have direct access to kernel-mode databases; concurrent access is coordinated by the database run-time. The databases are also made available to user-mode applications via a set of public interfaces implemented via system calls (see diagram, below).

The eXtremeDB-KM package

McObject’s eXtremeDB-KM package offers specialized development tools, complete source code, and example programs. One example kernel module provided with eXtremeDB-KM checks a given operation against access rules stored in the database. A related user-mode example program provides the interface to define and change rules stored in the kernel-mode database.

eXtremeDB Kernel Mode is available to kernel processes directly. User-mode applications interact with eXtremeDB-KM using a set of public interfaces implemented via system calls to a kernel mode proxy.