Ph.D. - geht es zur Homepage der Informatik des Fachbereiches 3 ...
Ph.D. - geht es zur Homepage der Informatik des Fachbereiches 3 ...
Ph.D. - geht es zur Homepage der Informatik des Fachbereiches 3 ...
Create successful ePaper yourself
Turn your PDF publications into a flip-book with our unique Google optimized e-Paper software.
6.2. Hardware Virtualisation<br />
in a virtual machine. This means, in the worst case other, components only have to<br />
cope with the unavailability of other components in the corr<strong>es</strong>ponding virtual machine<br />
or false data delivered or sent by them.<br />
Adv.2: Each hardware device and its software interfac<strong>es</strong> are protected from direct acc<strong>es</strong>s<br />
from software components executed in a virtual machine. Several implementations of<br />
hardware virtualisation hypervisors already provide for certain bus-typ<strong>es</strong>, like USB,<br />
the possibility to configure the acc<strong>es</strong>sible devic<strong>es</strong> in a certain virtual machine.<br />
Adv.3: Virtualisation reduc<strong>es</strong> dramatically the costs of partitioning analysis because software<br />
components executed in a virtual machine can only have an impact to other components<br />
over defined and known channels or interfac<strong>es</strong>.<br />
Adv.4: Platform dependent source code can be executed in any (proprietary) operating system<br />
and do<strong>es</strong> not influence the choice of the host operating system.<br />
Adv.5: Costs for hardware could be reduced because one hardware platform can host several<br />
operating systems.<br />
Adv.6: Virtual machin<strong>es</strong> can be easily maintained or (re)installed because their hard disk<br />
imag<strong>es</strong> can simply be copied.<br />
There exist also some disadvantag<strong>es</strong> and unsolved problems:<br />
Prob.1: Hardware virtualisation itself do<strong>es</strong> not implicitly provide any mechanism to protect<br />
the bandwidth of real hardware r<strong>es</strong>ourc<strong>es</strong>, like the CPU(s) or the network interface(s)<br />
on the host system. A hypervisor proc<strong>es</strong>s can be assigned to a certain CPU (in<br />
a multi-core system), which would at least protect the bandwidth of other cor<strong>es</strong>.<br />
Otherwise, if a (faulty or malicious) implementation consum<strong>es</strong> too much bandwidth,<br />
it may influence any other executed implementation and limit its functionality.<br />
Prob.2: Current open source hypervisors implementations are not too complex to be validated<br />
and certified [15], but which is currently for typical multi-user operating systems<br />
impossible because of their complexity. This means although the hypervisor can be<br />
assumed to be trustworthy that the operating system cannot. Therefore, the operating<br />
system itself may cause security problems.<br />
Prob.3: Overhead for computation, main memory, and storage space is generated because<br />
each virtual machine needs physical memory, each virtualised operating system needs<br />
additional computation time, and each virtual operating system needs physical storage<br />
space.<br />
Prob.4: Acc<strong>es</strong>s to shared memory outside a VM is not possible even if it is d<strong>es</strong>ired. Communication<br />
with proc<strong>es</strong>s<strong>es</strong> outside a VM can only be done by mechanisms also used for<br />
communication between different computers / hardware platforms that is typically a<br />
network or memory mapped fil<strong>es</strong> on a shared file system.<br />
Prob.5: Direct acc<strong>es</strong>s to hardware devic<strong>es</strong> or their interfac<strong>es</strong> is only possible for certain<br />
bus-typ<strong>es</strong>.<br />
Possible solutions for the problems Prob.1 till Prob.5 are introduced in the following subsections.<br />
71