However, under the circumstance where security is more important than execution efficiency, in some cases a data copying process can be used. By placing shared memory in the memory area of the OS that you want to isolate for security reasons, the effects of unauthorized access are minimized. FOXvisor offers this option. Normally, FOXvisor would prepare the shared memory area in an area accessible from all OSs.
To avoid this situation, FOXvisor creates a secure, isolated shared memory area in the memory area of the OS. Figure 2 shows an example of creating a shared memory area when using Linux. In this configuration, the other OS or FOXvisor reads and writes the memory area of Linux set to non-secure mode, and the OS that accesses shared memory is limited only to the OS that communicates with Linux. Even if an unauthorized application tries to access and capture the shared memory, its impact will be limited. Therefore, if security is more important than execution efficiency, the shared memory needs to be configured using this method, ideally fast, no major overhead to the processor, and with small footprint.
The development of a virtualization machine from companies’ own development teams is not an easy task, and it is associated with a variety of difficulties. Developing with a hypervisor means that two OS are running in parallel. For development with a Rich OS, like LINUX, software engineers need expertise in RTOS also, while RTOS engineers need expertise in development with a Rich OS. The complexity is enormous. The major challenge, however, is to be sure that the designed hypervisor is working securely. A system’s performance requirements need to be met, whereas the original OS code may not be touched, as the OS vendor will stop any support once the OS gets modified. The virtualization system has to run on each and every new release of the OS software, which means that maintenance for the latest OS versions is not trivial. To avoid technical support issues from the OS vendor, OS vendors lock-in is useful. However, this increases development costs, while support in progress could be slow, due to slow reply and poor communication. The re-usability of past software developments might also be limited. Even after completion of the hypervisor porting, the security software might not be compliant with the existing environment. Firmware and other updates also add complexity to hypervisor development.