Information Technology Reference
In-Depth Information
3.1 State Provider
The
state provider
computes the effects of an event on the current state and
converts the trace events into
state changes
. It observes the type and contents
of all events in the trace one by one (using a
switch/case
for example), and
updates the modeled state accordingly.
It is possible for events to cause several state changes, or no change at all
(n-to-m relationship). For instance, a file close event changes the state of the
corresponding file to “closed”, and linux sched switch (p1, p2) event changes
the states of two processes, one to “waiting” and the other to “running”, respec-
tively. The state provider module uses a mapping table which contains different
mapping rules, from a simple “if x then y” rule to complex state transition pat-
terns, depending on the type of event and its effects on the status of the system
resources.
Therefore, the state provider module needs to know, for example, the types
of events that will be presented in the trace, their names and contents. This
is the only part of the modeled state that is platform-specific, and should be
customized for any new trace format. A possible solution to make this part also
generic is to inject the mapping table dynamically, e.g. though an XML file.
This will be investigated as a future work.
The state provider should also be aware of the various outputs of other analysis
modules. For instance, higher level synthetic events, which are typically created
using different trace abstraction techniques [EJD12], may in turn be used to
further modify the system state. For example, several low level events may be
used to create a “brute-force attack” abstract event, which could change the
state of the system to “compromised”.
The state provider is a critical part of the system. It is called for each event
in the trace and updates the state database for each change. It is therefore im-
portant that it is optimized. One method is to avoid recording redundant or
unnecessary state changes. Another method, the partial history update, is to
update the state database for a group of state changes (each 10 state changes),
instead of at each state change [EJD13]. This significantly reduces the amount
of information to be recorded. The impact of the state provider on system per-
formance, using both the complete and partial history updates, will be shown in
the experimental results section.
3.2 Attribute Tree
We define a general term, “attribute”, as any basic unit of the modeled state
system, which can contain only one state value at any given time during the
execution. An attribute can be basically anything, as it is defined by applications.
For example, “name or ID of the process scheduled on CPU 0”, “the name of an
open file” or “the number of active processes” could be attributes in the model.
With this definition, each attribute can be used to describe a system resource,
but a resource may also have several attributes to describe its different aspects,
e.g. parent process id of a process, exec name of a process, fd (file descriptor)
of a file, address of a socket, and so on.
