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.

Get Open Systems Dependability now with O’Reilly online learning.

O’Reilly members experience live online training, plus books, videos, and digital content from 200+ publishers.