# Secure and Dynamic Memory Management Architecture for Virtualization Technologies in IoT Devices
## 3 Virtualization on Embedded Devices  
Embedded devices were initially used to run a single real-time application. The improvements in embedded hardware performance resulted in the ability to run multiple real-time applications on the same embedded platform. Sharing resources among multiple real-time applications causes security and performance issues. Providing separate execution environments (isolation) for real-time applications is a security and performance requirement in embedded platforms [17]. Virtualization technology can be used to fulfill these requirements. Virtual machine technology provides isolation at the middle layer (i.e., the process layer) of IoT information flow architecture. Virtualization technology is mainly used in embedded devices to run normal and real-time operating systems (RTOSs) concurrently [17; 18; 19; 20]. The difference between real-time operating systems and normal operating systems is that in a real-time operating system, the response time of instruction execution demands a guaranteed throughput rather than a high throughput [21] as required in a normal operating system. That means the response time or the time taken to complete the task can be predicted with 100% accuracy at the time of system design. Hence, the response time of embedded systems is also known as predicted time. That means the latency (delay over the predicted time) of execution of instructions should be less than or equal to zero for real-time operating systems. A latency greater than zero indicates failure of the real-time system [21]. The predicted time for instruction execution in the virtual real-time operating system should be the same as in a normal real-time operating system. Regular hypervisors are designed to create virtual machines running general operating systems. Embedded hypervisors [22] are required to build virtual machines that run real-time operating systems. The embedded version of the renowned open source hypervisor Xen, called RT-Xen [22], is a real-time hypervisor for embedded platforms. ARINC 653 is another embedded hypervisor designed to provide spatial and temporal isolation for applications in the aviation industry. Several commercial RTOS products have adapted the ARNIC 653 design standards. A virtual RTOS running in the QPlus Hypervisor is reported to have performance degradation due to the delay in interrupt execution. The interrupt execution delay is due to the additional time consumed for virtual CPU (VCPU) scheduling. If the VCPU is assigned to a particular CPU, the predicted time of instruction execution in virtual RTOS and normal RTOS would be similar, as CPU virtualization is a time-based demultiplexing method [19; 23]. Hence, in real-time hypervisors, in order to achieve predicted time instruction execution on each virtual RTOS, the virtual CPU of each virtual RTOS should be directly assigned/pinned to the physical CPU. The SIGMA system is an example of such a system, designed such that a dedicated CPU core is assigned to each VCPU [19], to build a multi-OS environment with native performance. In this system, the interrupts to the CPU are rerouted to the corresponding virtual CPU with real-time performance [22]. In an embedded hypervisor, memory virtualization does not degrade performance, as memory is virtualized through spatial demultiplexing [19]. Additionally, the virtualization of Input/Output (I/O) device is done through memory [23]. Thus, the primary functionality of virtualization for an embedded hypervisor should be provided in the memory architecture. The embedded hypervisor architecture can be visualized as shown in Figure 2.  
A trusted computing base/secure execution environment is considered to be a major security requirement of a virtualized IoT infrastructure [24; 25; 26; 20]. Virtual machine isolation at different hardware levels (e.g., processor, memory, and networking) is essential for achieving a trusted computing base [27]. The ARM architecture uses ARM-TrustZone, a solution enabling two different zones to run on a single embedded platform [28].