8.1 Virtualization and Isolation Approaches on Mobiles

BYOD has been coined to describe the consumerization² of the IT. IT organizations are no longer interested in providing and provisioning the IT equipment for the individuals. Most of the companies in the past had a separate department for maintaining individual IT equipment so the approach of offloading the task of hardware/device to the individual can significantly benefit the organizations in terms of cost cutting, delays in providing IT services due to communication gaps between various departments, etc. [260].

IT organizations can simply provide cash incentive to individuals to bring their own device for work, and use organization approved Operating System (OS), device image, secured emulation environment, and antivirus software when working for the company using the device. The second aspect of BYOD is the advent of high-performance mobiles such as smartphones and tablets devices. In addition, the dramatic growth in computing services and mobility trends, e.g., 3G/4G on smartphones, enable consumers/workers to use their devices on the go as well as during normal work hours. This would come across both as an opportunity as well as a challenge for the organizations. The opportunity is present in the sense that it would lead to productivity increase and significant cost reductions. However, this also brings forth a lot of challenges especially from the security perspective for organizations.

The organizations have to make sure that the devices are secured from external threats and at the same time prevent data exfiltration and unauthorized access to the resources [251]. To address this issue, we need to design a new application running platform on mobiles at the edge of cloud infrastructure, which can serve as a proof of concept for implementation on a large scale.

In this chapter, we select the ARM architecture to serve as the base model. The reason for selecting the ARM platform is performance and ubiquity provided by the ARM devices. The solution would be a KVM/ARM virtualization solution. The other benefit of using KVM is that it is an in-built kernel module, so we can keep KVM/ARM in lines with new kernel releases without the additional maintenance costs. The solution will have host operating system running KVM environment and unmodified guest OS would be running in the emulation environment provided by the host OS [92]. Virtualization can in the future be extended to provide other features such as high availability, load balancing features, etc.

The presented work will make use of a software switch solution – Open vSwitch (OVS)³ [227] – to establish a networking framework between the host OS and guest OS. This will bring in the scope of introducing programmability into the network using Software Defined Networking (SDN)⁴ solution [246]. Programmability in the network will help us build a flexible OpenFlow [197] based framework for our system. OpenFlow is a protocol that allows a server to tell network switches where to send packets. OpenFlow is an implementation to realize the SDN concept. In a conventional switch, packet forwarding (the data path) and high-level routing (the control path) occur on the same device. An OpenFlow switch separates the data path from the control path. The control plane of SDN will have direct control over the Data Plane elements [219]. This will help deal with issues in traditional networks like devices from different vendors and two separate devices from same vendors. In this way, individuals can bring any smart phone/tablets of their choice as long as they have the virtualization feature support. The network of emulated virtual machines would be easily managed by the organization.

We will compare our solution with other mechanism of introducing BYOD security in IT enterprises and see why this solution will be significantly better than other proposed solutions such as Prioritized Defense Deployment for BYOD; feedback based strategic sampling for BYOD security, application Sandbox,⁵ etc. The novel aspect of this solution is that using OVS we can introduce the SDN framework and correspondingly programmability in a edge cloud network. It will make the solution vendor agnostic. In this way, we can virtualize and manage the devices from different vendors as long as they support virtualization feature. Since ARM CPUs are common in many smartphone devices, e.g., Samsung Galaxy S5 uses ARM Exynos 5250, the proof of concept can then easily be deployed in real world scenarios, and tested for performance and security aspects. Other important contributions of the work are that it will have significant cost savings, secured environment for managing the VMs, and better scalability as compared to some of the existing BYOD solutions.

The presented solution is a base model/prototype serving as experimental platform for BYOD framework. The ARM CPU provides hardware virtualization extensions so we make use of KVM virtualization on base ARM Development board for booting up the host OS and make use of KVM and emulation software QEMU [62] to boot up the guest OS on top of host OS in hypervisor mode. The OVS feature will be installed on top of Host system so that we can introduce SDN framework on host OS and manage guest OS. The details of prototyping and implementation are presented in Appendix D.

8.2 System Design and Architecture

This section introduces the design methodology and approach used for setting up a BYOD framework. Virtual Open System [35] and Linaro Networking Group [20] have focused their efforts on virtualization of ARM. KVM/ARM project [91] started as a research project at Columbia University and is also supported by Virtual Open Systems. Linux kernel 3.9 and beyond provide KVM support for ARM architecture [93].

Since ARM CPU have become common in mobile devices, tablets, servers, so there is a growing demand of utilizing the virtualization benefits for ARM devices. Split mode CPU virtualization offered by ARM/KVM solution allows hypervisor to split execution across CPU modes. The architecture introduces three modes – the normal user mode USR, the kernel mode SVC for running privileged instructions, and a new HYP mode that is more privileged than SVC mode. There are several changes in terms of OS architecture, for instance, HYP mode only maintains a single page table base register, and there is no address space split between the user and kernel modes.

The kernel is by default booted in HYP mode. This makes the architecture backward compatible with the legacy systems since the kernel always boots in SVC mode in legacy systems. Preboot stub known as “decompressor” decompresses kernel image into memory. On detecting that it booted in HYP mode, a temporary stub must be installed which would allow the kernel to fall back to SVC mode and run the decompressor code.

Other architectural details of KVM/ARM such as hardware trap, Virtual Generic Interrupt Controller (GIC) and timers have been discussed in [93]. Various development boards have been used as base models by the organization Virtual Open Systems [259] such as TI – OMAP 5432 [45] based on ARMv7 architecture, Samsung Exynos 5250 [46] based on ARMv7. Fast Models based simulation platform, which could be a good potential solution for KVM/ARM on Juno development board by ARM [147].

The presented model is based on the same KVM/ARM architecture, where VMs can be booted on top of ARM based development boards. Moreover, we use OVS to create a bridged network of guest VMs on top of Host VM. This allows us to implement network wide policies, firewall rules, load balancing solutions on guest VMs using a smart OpenFlow controllers, such as POX [159], OpenDayLight [199], etc.

8.2.1 System Components

The goal is to build a BYOD framework that allows easy implementation of corporate policies and data capture for analysis. Two essential components of this framework are hardware assisted virtualization and Open vSwitch.

Hardware Assisted Virtualization

The base model for experimentation and evaluation are ARMv7 based development boards, hence the discussion focuses on the hardware assisted virtualization that ARM offers as part of ARMv7 and ARMv8 releases [109]. The RISC architecture of ARM helps achieve good balance of high performance, small code size, low power consumption, and reduced silicon area [56]. In addition, many smartphones and handheld devices have ARM based processors-with multiple cores. ARM architecture virtualization extensions and Large Physical Address Extension (LPAE) [118] enable efficient implementation of VM hypervisors for ARM architecture compliant processors.

To illustrate how ARM-based security framework works, i.e., TrustZone, Fig. 8.1 highlights the system architecture. TrustZone splits the mode into two worlds – secure and nonsecure. A special mode – monitor mode is used to switch between secure and nonsecure worlds. Although secure mode does not work in HYP mode, since trap and emulate support is not present, still we can run sensitive applications in the secure world. In [94], the authors discussed secure world and other details about CPU, memory, timer, and interrupt virtualization of ARM.

Open vSwitch

Virtual switches connect the interfaces of VMs and establish connection to outer network with the help of Physical Network Interface Card (pNIC). Open vSwitch (OVS) is used extensively in OpenStack and OpenNebula. We can explore broad range of OpenFlow features via software switches that cannot be provided by hardware switches. Two important parts of OvS are ovs-vswitchd daemon that controls switch and is responsible for implementing OpenFlow protocol, and datapath kernel module to implement the packet forwarding [103].

The performance comparison of various forwarding techniques as shown in Table 8.1 with a single CPU core per VM and a switch is discussed in [103], which suggests that Open vSwitch proves to be the fastest Linux kernel packet forwarding application.

Table 8.1

Open vSwitch Performance Analysis

Application	pNIC–pNIC [Mbps]	pNIC–vNIC [Mbps]	pNIC–vNIC–pNIC [Mbps]	pNIC–vNIC–vNIC [Mbps]
Open vSwitch	1.88	0.85	0.3	0.27
IP Forwarding	1.58	0.78	0.19	0.16
Linux bridge	1.11	0.74	0.2	0.19
DPDK vSwitch [149]	11.31	–	10.5*	6.5*

Also rule-based system used by Open vSwitch would make it easier to configure a generic OpenFlow controller for VMs connected to Open vSwitch and implement access control based on the flows, e.g., blocking packets from a compromised VM or redirecting packets to a different destination. The SDN model thus formed can be made more scalable by configuring a controller that is logically centralized but physically distributed, e.g., HyperFlow [263]. Open vSwitch across two host systems can also communicate via a Generic Routing Encapsulation (GRE) [106] tunnel.

8.2.2 System Architecture

The system architecture for BYOD framework uses Samsung Exynos 5250 as base platform for demonstration purposes. The board was first introduced in 2012 and features two Cortex-A15 cores clocked at 1.7 GHz [132]. It offers 50% higher per MHz performance compared to commonly used Cortex A9 architecture. It is lightweight (150 g) and is common in many handheld devices such as Google Nexus Tablet. It is also very cost effective at about $150/board. The goal is to develop the framework on this platform so it can later be used for deployment in a larger testing environment or code base from this platform to be deployed on other tablets or mobile devices compatible with ARM architecture.

The architecture consists of three basic features:

•  As shown in the Fig. 8.2, the host OS should have hardware assisted virtualization enabled and should boot in HYP mode enabled. Ubuntu Precise (12.04) is used as the host OS. The host operating system needs a Device Tree Blob (DTB)⁶ exynos5250-arndale.dtb, which contains description of hardware. It is specific to the development board. Another component required is the kernel uImage. Details of generating both are discussed in Appendix D.

•  Open vSwitch is run on top of a host platform. This allows us to make use of OpenFlow APIs along with other advantages of Open vSwitch. An important consideration for this prototyping is compatibility of Open vSwitch with the Linux kernel. Table 8.2 shows the compatibility of Linux kernel with Open vSwitch versions. Therefore, we are choosing Linux kernel 3.14.32 and Open vSwitch version “openvswitch-2.3.1”.

Table 8.2

Open vSwitch and Linux kernel version compatibility

Open vSwitch	Linux kernel
1.4.x	2.6.18 to 3.2
1.5.x	2.6.18 to 3.2
1.6.x	2.6.18 to 3.2
1.7.x	2.6.18 to 3.3
1.8.x	2.6.18 to 3.4
1.9.x	2.6.18 to 3.8
1.10.x	2.6.18 to 3.8
1.11.x	2.6.18 to 3.8
2.0.x	2.6.32 to 3.10
2.1.x	2.6.32 to 3.11
2.3.x	2.6.32 to 3.14
2.4.x	2.6.32 to 4.0

•  A guest OS can be booted using the bridged network provided by Open vSwitch. Additionally, the guest OS requires the kernel image to boot the guest OS zImage,⁷ the DTB file, file system image to boot guest, a modified version of QEMU to emulate, and drive KVM from the userspace.

8.3 Communication with Remote OpenDayLight Controller

An SDN remote controller can be used for managing and monitoring the network traffic flow, and achieving the functionality of an SDN network. As shown in Fig. 8.3, the controller used is OpenDayLight (ODL) [199], where the modular approach provided by OpenDayLight project helps provide SDN functionality and achieve solid platform for other important features such as NFV (Network Function Virtualization)⁸ [126]. The ODL controller can remotely set up the traffic flow policies on mobiles through OpenFlow protocols [255] and interact with Open vSwitch (OVS) that assumes each guest is an isolated VM on a mobile device (i.e., a VM host). For information about network virtualization and OpenFlow protocols, please refer to Chapter 2, Section 2.5, where an introduction to SDN and OpenFlow protocols is presented.

Using OpenFlow protocols, the Northbound APIs of the OpenDayLight controller can be used for providing the application development functionality through an abstraction layer. The southbound API will connect to the Open vSwitch presented on Samsung Exynos 5250. The controller is very useful for managing the VM in a BYOD scenario. In case of network events such as DoS attacks targeting a particular mobile device, the controller can have an intrusion detection mechanism configured to monitor application protocols and traffic, and then detect breaches or DoS attack patterns.

For detailed implementation and testing, please refer to Appendix D.

8.4 What Is the Next Step?

Mobile devices such as smartphones and tablets will certainly play a role in a future work setting of each organization. BYOD using an SDN framework can prove very efficient, scalable, and secure solution for organizations in the future. The model in this work uses ARMv7 as a proof-of-concept that ARM is a cost-effective, fast, and stable platform for serving as a base model for such devices.

ARMv7 is a good prospective platform for BYOD implementation. Future work should focus on the implementation of the model in a real application scenario. For example, we have been working on a mobile testbed consisting of 4 Unmanned Ground Vehicles (UGVs) and 6 Unmanned Aerial Vehicles (UAVs). This board being lightweight can be a suitable candidate to be deployed on UAVs. The robotic control functionality for UGVs would be provided by Arduino Uno Development board [55], which is standard for common robotic projects, and UAVs would make use of Ardu Pilot Board [101] with a compatible camera. Since Arduino platforms do not come with sufficient computing capability and the signal and network traffic analysis for testbed would require a platform with good computing capability, Samsung Exynos 5250 can be integrated with Ardu Pilot to provide computing capability.

Another important direction is to incorporate lightweight virtualization solutions, such as using containers (Docker [265]), which will make the mobile spend less overhead to manage heavy VM-based virtualization solutions.