Ph.D. - geht es zur Homepage der Informatik des Fachbereiches 3 ...

6.2. Hardware Virtualisation
a fixed size s: ∀e : ∀l : s e,l = {p e,l,0 , p e,l,1 , . . . }, length(s e , l) > 0, V ≥ ∑ n
e=0
∑ m
l=1 length(s e,l),
∀k : length(p e,l,k ) = s [77, pp. 353-453].
This strategy is used in most of the current multi-user-multiprocessing operating systems,
like GNU/Linux.
6.2. Hardware Virtualisation
Section 6.1 described traditional strategies for avoiding the influence of faulty or malicious
components on the rest of the system. This strategy must be integrated in the hardware 1 and
the software and/or the operating system. That means for the usage of these strategies, it is
important how the hardware platform and the operating system are chosen.
This is often problematic because open source software is typically not limited to a certain
hardware or software platform. For a concrete open model software for industrial usage, this
is almost mandatory because during its development not all potentially used hardware and
software platforms can be known in advance. This leads to the need for another mechanism for
memory protection that better fulfils the requirements of open model software in industrial
applications.
The solution proposed in this work is the usage of hardware virtualisation [92]. Ideally,
each supplier implementation or program should be executed in a separated virtual machine.
The term virtual machine (VM) refers to the hardware virtualisation of any operating system
representing a computer. Since a VM is completely separated from its host’s operating
system, the virtualised operating system does not have any direct access or knowledge about
it. Programs executed in a VM can only communicate via a (virtual) network or a shared file
system with programs on the host system or on other VMs.
The application of the hardware virtualisation concept to the initial problem of open models
is shown in Figure 6.3. It holds the generated and certified model implementation and the two
supplier implementations from Figure 6.2, but, in contrast, all supplier implementations are
now locked in own virtual machines. This assures that the malicious implementation cannot
compromise any other part of the software while a communication still is possible.
This hardware virtualisation concept fits the typical use cases of open model software in
industrial applications because:
• Supplier implementations in a VM can never access memory of the host system or any
other VM independent from the used operating system or memory management strategies
and can only communicate with other components over defined and known channels.
• There exist several OSS / FLOSS implementations for hardware virtualisation, e.g.,
QEMU (KVM) [73], VirtualBox [66], Xen [97], and User Mode Linux [91].
Furthermore, the usage of hardware virtualisation provides additional advantages compared to
traditional memory management strategies:
Adv.1: Hardware virtualisation protects the host operating system from any kind of negative
and direct influence by failures, errors, or malicious behaviours of components executed
1 typically CPU and MMU
69