A system to analyze KErnel-mode Drivers in Runtime. The tools provided by KEDR rely heavily on the means to intercept calls made by the kernel module under analysis. These call interception facilities are provided by the core components of KEDR.

A kernel module to be analyzed.

To perform analysis of the target module, it can be necessary to intercept calls to some functions made by it. These functions are called target functions. For example, to analyse how memory is allocated and freed by the target module, one may need to intercept calls to __kmalloc(), kfree(), etc.

The target functions can be exported by the base kernel (“kernel core”) or by other kernel modules.

By choosing appropriate payload modules, the user may select the groups of functions the calls to which are to be intercepted.

KEDR system instruments the target module so that the calls to the target functions are replaced in it with the calls to special replacement functions.

A replacement function has the same signature as the corresponding target function. When the replacement function is called, it receives the same argument values as the target function would. The replacement functions can be provided by the user (via custom payload modules). A replacement function may, for example, simply call the target function to let it do its work and then just output its arguments and the return value to a trace. Or it may collect some other data or even simulate a failure of the target functon (without actually calling it).

Apart from having the same signature as the corresponding target functions, KEDR system imposes no additional restrictions on the replacement functions.

A payload module is a kernel module that actually contains replacement functions for a particular group of target functions. The core components of KEDR use this data when instrumenting the target module. Each payload module specifies the calls to which functions should be replaced with the calls to which functions.

It is payload modules rather than KEDR core that define which data should be collected about the target module, how the execution of the latter should be altered (if it should be at all), etc. Different sets of payload modules may allow to perform different kinds of analysis of the target module.

Currently, KEDR provides payload modules for several types of data collection and analysis operations. Custom payload modules can be provided by the user. As long as the payload modules rely on the API defined by KEDR, KEDR makes no difference between the payloads provided with it and the ones supplied by the user.

Fault simulation is one of the many ways to check reliability of a target kernel module. It can be used, among other things, to see if the target module behaves correctly when the operating system fails to complete its requests. For example, you may want to find out if the target module crashes the system when there is not enough memory for its operations or if there is no contiguous memory block of a size greater than N, etc.

KEDR allows to perform fault simulation on the target module. The scenarios (what function calls to make fail and in what conditions) can be provided and configured by the user as well. A number of common scenarios is already supported by KEDR by default.

The fault simulation scenarios are defined by the fault simulation points (“What to make fail?”) and fault simulation indicators (“In what conditions should this fail?”).

Fault simulation point is a location in a kernel module where it should be decided whether to continue execution as usual (“normal path”) or go to a path provided to handle an error of some kind (“error path”) or something else. This is similar to an ordinary conditional construct in a module. The decision, however, is made based on some predefined scenario rather than on the actual presence of the error conditions.

A scenario for a simulation point may be contrived. Sometimes, it does not even take into account whether the normal path and the error path are possible. For example, the default memory allocation manager may return error only if there is no memory chunk of appropriate size. A custom allocation manager, however, may contain a fault simulation point with a scenario that additionally prescribes to make every second allocation request fail, no matter the requested size.

In KEDR, fault simulation points are used in the replacement functions. This allows to simulate failures of the target functions according to user-defined scenarios and to see if the target kernel module handles these failures properly (see Fault simulation). In the normal operation of the target module, such failures can be very rare. Therefore, errors in handling of these failures can be harder to notice and debug. KEDR facilitates checking such paths in the target module.

A fault simulation indicator is usually a function used in a fault simulation point to make a decision, whether to execute “normal” or “error path” in the code. More often than not, it is a boolean function which returns values corresponding to “make fail” and “do not make fail” decisions. One might say that an indicator implements the scenario for a fault simulation point (i.e., it answers to the question, “In what conditions should this fail?”).

In KEDR, fault simulation points and indicators are largely independent on one another. That is, a fault simulation point may use almost any indicator and the indicator can be easily changed at runtime. The only restriction is that if an indicator expects some parameters from the point, the indicator can not be set for the point that does not provide these parameters. For example, consider an indicator implementing the following scenario “make this fail if size parameter is greater than 1024”. If a particular fault simulation point corresponding to some target function has nothing like size parameter, KEDR will not allow to use that indicator for this point (it makes no sense anyway).