Open Systems Dependability

This chapter describes a DEOS runtime environment (D-RE) for

realizing the DEOS process and its architecture. The DEOS process

and architecture require the following fi ve functions: monitoring,

reconfiguration, scripting, recording, and security, which are

described in Section 6.1. It is necessary to adapt or customize a D-RE

to a target system according to its dependability requirements (and

functional requirements) as agreed upon by the stakeholders. Several

D-RE customization options and examples are discussed in Section

6.2. Two cases of the implementation of the D-Visors and D-System

Monitors are described in Section 6.3. Finally, security mechanisms

introduced into the D-RE is described in Section 6.4.

6.1 D-RE FUNCTIONS

6.1.1 Monitoring

The D-RE monitors system components, including application

programs and operating systems, in order to detect various anomalies

in a target system. D-RE provides the following monitoring

facilities:

• D-Application Monitor, which monitors application programs

and collect logs designated by D-Case Monitoring nodes,

• D-System Monitor, which monitors operating systems and

collect logs designated by D-Case Monitoring nodes.

RUNTIME ENVIRONMENT FOR DEOS

RUNTIME ENVIRONMENT FOR DEOS

PROCESS AND ARCHITECTURE

PROCESS AND ARCHITECTURE

6

6

74 Open Systems Dependability

The D-Application Monitor has two distinct mechanisms:

monitoring resource abuse and tracing application-specifi c events.

An anomaly can be detected from a combination of these two types

of monitored data. D-System Monitor currently focuses on detecting

various kernel infections such as key loggers and kernel rootkits.

D-System Monitor itself has two classes of mechanisms, one to

detect kernel level anomalies and the other to repair anomalies in

the kernel.

6.1.2 Reconfiguration

Reconfi guration is a function to change the structure of a target

system. This function is activated when anomalies are detected or

when failures occur. The reconfi guration requires the capability to

isolate a set of operating systems and applications within a single

logical partition and/or to isolate an application from others, with

an appropriate resource allocation policy for each logical partition

or isolated application.

In D-RE, two levels of containers are introduced:

• System container: a logical partitioning of a system with all its

entities,

• Application container: a logical partitioning of application

groups, isolating each address and name space.

The system containers enable multiple operating systems to run

independently of each other, whereas the application containers

enable multiple application programs to run independently of each

other. Each of these containers has its own runtime environment for

programs, and is a unit of restarting the programs run in it. These

levels of containers need to be customized based on the stakeholders’

dependability requirements when D-RE is applied to real systems.

Eleven items are defi ned which need to be isolated from others as

shown in Table. 6-1.

An application container can extend its container across networks

in the case that an application runs on multiple computers or servers.

Core services such as system clocks and units of measurement must

be provided by D-RE and should be isolated from the application

domain. These can be contained in the TCB (trusted computing base)

as described below.

Runtime Environment for DEOS Process and Architecture

Runtime Environment for DEOS Process and Architecture 75

The D-RE introduces two components: the D-Visor and the

D-Application Manager. The D-Visor provides system containers to

the upper layer of software. Its details will be described in Section

6.3. The D-Application Manager allocates application containers to

applications.

6.1.3 Scripting

D-Script consists of a set of scenarios, which is derived from

Service Continuity Scenarios. Two classes of D-Script elements

are introduced: D-Task and D-Control. D-Task is an atomic unit

of execution. D-Control is used to designate sequential execution,

conditional branching, and parallel execution of D-Tasks. D-Script is

written in a scripting language called Konoha (Kuramitsu 2011).

In order to securely execute D-Script, the D-Script Engine is

introduced. The D-Script Engine ensures that D-Script is executed

within a trusted runtime environment in the target system. The

D-Script Engine has an integrated compiler that enables static type

checking and security checking of given scripts, and executes the

Table 6-1 Items for Isolation.