Virtualization Technologies and Cloud
`Security: Advantages, Issues,
`and Perspectives
`
`Roberto Di Pietro!) and Flavio Lombardi?
`
`' Information and Computing Technology Division, College of Science
`and Engineering, Hamad Bin Khalifa University, Doha, Qatar
`rdipietro@hbku.edu.qga
`2 Istituto per le Applicazioni del Calcolo, Consiglio Nazionale delle Ricerche,
`Rome, Italy
`flavio.lombardi@cnr.it
`
`Abstract. Virtualization technologies allow multiple tenants to share
`physical resources with a degree of security and isolation that cannot be
`guaranteed by mere containerization. Further, virtualization allows pro-
`tected transparent introspection of Virtual Machine activity and content,
`thus supporting additional control and monitoring. These features pro-
`vide an explanation, although partial, of why virtualization has been an
`enabler for the flourishing of cloud services. Nevertheless, security and
`privacy issues are still present in virtualization technology and hence
`in Cloud platforms. As an example, even hardware virtualization protec-
`tion/isolation is far from being perfect and uncircumventable, as recently
`discovered vulnerabilities show. The objective of this paper is to shed
`light on current virtualization technology and its evolution from the point
`of view of security, having as an objective its applications to the Cloud
`setting.
`
`Keywords: Virtualization - Security - Cloud
`
`1
`
`Introduction
`
`The advances in virtualization technology of the past decade have rendered the
`Cloud approach feasible and convenient. Nevertheless, the main limitation of vir-
`tual machines is that they were born as a means to easily migrate from physically
`deployed services to more compact and manageable images. In fact, each and
`every VM runs its own full operating system together with the various libraries
`required by the application (see Fig. 1) [35]. Such an approach multiplicates the
`usage of RAM, CPU, and storage with respect to simply hosting multiple services
`as separate processes on a single piece of bare metal.
`Containerization technology is intended to replace hypervisor and VMs, and
`deploys each application in its own process-like environment running on the
`physical machine on a single operating system [42]. Containers can be provi-
`sioned (and deprovisioned) in a few seconds and make a more efficient usage
`
`© Springer Nature Switzerland AG 2018
`P. Samarati et al. (Eds.): Jajodia Festschrift, LNCS 11170, pp. 166-185, 2018.
`https://doi.org/10.1007/978-3-030-04834-1_9
`
`WIZ, Inc. EXHIBIT - 1028
`WIZ, Inc. v. Orca Security LTD. - IPR2024-00220
`
`WIZ, Inc. EXHIBIT - 1028
`WIZ, Inc. v. Orca Security LTD.
`
`

`

`Virtualization Technologies and Cloud Security
`
`167
`
`of resources, achieving a much higher application density (orders of magnitude
`[37]) than virtualization. This renders containers much more convenient than
`virtual machines.
`Nevertheless, as we will show along this paper, virtualization is not on a
`dead path. In fact, virtual machines provide additional security mechanisms
`and isolation benefits in many application scenarios that are often worth the
`additional resource usage [28,39].
`A virtualization environment generally consists of three core components: an
`hypervisor or Virtual Machine Manager (also VMM in the following), manage-
`ment tools, and Virtual Machines (VMs). In particular, the infrastructure-as-
`a-service (laaS) Cloud layer directly leverages and exposes powerful virtualiza-
`tion technologies and resources to a remote user [3]. Nevertheless, virtualization
`technologies also introduce additional security concerns. The size of the attack
`surface for the virtualization approach is directly proportional to the amount of
`emulated physical resource or functionality that must be provided in software.
`As regards containers, they can leverage all services offered by the host OS,
`so the issue here is to enforce effective security and isolation among processes.
`This is actually more difficult to do, since OSes have not been designed with
`this in mind. Further, the partitioning/virtualization modes and ISAs! of recent
`CPU and GPU cannot be used by containers, as they are inherently part of vir-
`tualization and introduce the actual performance penalties of traditional VMs.
`Unikernels can be considered an alternative to both containerization and virtu-
`alization. They maintain some of the benefits of other approaches (lightweight
`and isolated) but introduce further issues such as manageability, monitoring and
`reliability.
`In this paper, we survey various aspects of virtualization, analyze their impact
`on security, and discuss future perspectives. In particular, we provide technol-
`ogy background for most widespread virtualization tools in order to highlight
`features, advantages and potential security flaws, with a focus on their applica-
`tion to Cloud. Further, discussions and comparisons with containerization and
`unikernel approaches are introduced throughout the paper.
`The sequel of this paper is organized as follows: a technology background is
`provided in Sect. 2; most relevant virtualization security issues are introduced in
`Sect. 3; virtualization-based security approaches are presented in Sect. 4; novel
`enclave technology is discussed in Sect. 5; virtualization-based use cases, together
`with some future research trends, are presented in Sect. 6; and, finally, conclu-
`sions and hints for future work are given in Sect. 7.
`
`2
`
`Technology Background
`
`Various different virtualization technologies are currently deployed in the Cloud,
`mostly for x86_64 architectures (e.g., Xen, KVM, VMware, VirtualBox, and
`HyperV). Most relevant details on virtualization frameworks and on supporting
`hardware (CPU/GPU) features are given and discussed in the following sections.
`
`1 Instruction Set Architecture(s).
`
`

`

`168
`
`R. Di Pietro and F. Lombardi
`
`
`
`(oe Bl
`
`Content
`
`Collaboration
`
`Communication
`
`AN
`
`Runtime
`
`Object
`Storage
`
`和 一
`
`
`L_
`Database
`
`/
`™~
`
`
`
`Guest OS
`
`Guest Kernel
`
`本
`一
`
`
`
`
`
`Hypervisor
`
`a
`
`AAA
`
`
`
` ( HW (CPU/GPU/Disk/Net) }
`
`
`
`Fig. 1. Cloud layers and virtualization
`
`2.1
`
`Virtualization Frameworks
`
`The essential characteristics of the most widespread virtualization environments
`are summarized in Table 1.
`It
`is worth noting that all present hypervisors sup-
`port full virtualization (also hardware-assisted virtualization in the following),
`as it offers relevant performance and isolation benefits. In fact, hardware virtu-
`alization allows the CPU to detect and possibly block unauthorized or malicious
`access to virtual resources. Nevertheless, no virtualization framework is immune
`to bugs. The virtualization platform can be an additional attack surface.
`
`2.2
`
`CPU Virtualization
`
`The introduction of virtualization-enabling extensions in Intel and AMD CPUs
`dates back to 2005 [1,25]. VT-x and AMD-V were developed to add an additional
`more privileged execution ring where an hypervisor or virtual machine manager
`(VMM) could supervise actual access to physical resources from less privileged
`execution rings, as depicted in Fig. 2.
`CPUs are required to support some advanced extensions in order to allow
`the hypervisor to leverage them, as can be seen in Table 1. More in detail:
`
`- Intel VT-x AMD-V: These two CPU capability sets are the basic ingredi-
`ent of hardware-supported virtualization. They introduce Ring —1 allowing a
`guest virtual machine to run its kernel at standard privilege level (i.e., Ring
`0);
`
`

`

`Virtualization Technologies and Cloud Security
`
`169
`
`Table 1. CPU-related virtualization features
`
`
`
`X86_64 hypervisor | Open source | Hypervisor type | Supported extension(s)
`
`
`
`Xen
`
`Y
`
`Native
`
`VT-x, AMD-V, EPT, RVI, VT-d, AMD-Vi
`
`
`
`KVM
`
`Y
`
`Hosted
`
`VT-x, AMD-V, EPT, RVI, VT-d, AMD-Vi
`
`
`
`VMWare ESX
`
`N
`
`Native
`
`VT-x, AMD-V, EPT, RVI, VT-d, AMD-Vi
`
`
`
`Hyper-V
`
`N
`
`Native
`
`VT-x, AMD-V, EPT, RVI, VT-d, AMD-Vi
`
`
`
`
`
`
`
`
`
`VirtualBox
`
`Y
`
`Hosted
`
`VT-x, AMD-V
`
`- Intel EPT, AMD RVI: Rapid Virtualization Indexing and Extended Page
`Tables, i.e. the Support for Second Level Address Translation (SLAT) that
`can significantly improve performance;
`~ Intel VT-d, AMD-Vi: These CPU capabilities (directed I/O) allow faster
`I/O resource virtualization.
`
`Lea st privileged
`
`
`
`
`
`
`
`
`
`
`Most privileged
`
`Gu
`
`
`
`
`
`Device drivers
`
`Device drivers
`
`Applications
`
`Fig. 2. Execution rings for the x86_64 architecture. See also [19]
`
`2.3.
`
`GPU Virtualization
`
`The virtualization paradigm also applies to Graphics Processing Units (GPUs).
`Virtual machines can be given mediated or full access to GPU computing and
`memory resources. This allows offering a GPU-based Cloud similar to what is
`in place already for CPU-based computing resource sharing. Hypervisor support
`for GPU virtualization features (see Table 2) is still somehow limited as relevant
`GPU technology is still reserved for high-end GPUs. In fact, GPU virtualization
`is usually implemented following one of these main approaches [24]:
`
`a time is given direct access to the GPU.
`一 time-sharing: a single VM at
`Time-slots are handled by the hypervisor;
`
`

`

`170
`
`R. Di Pietro and F. Lombardi
`
`一 passthrough: the GPU is directly and permanently connected to a single
`VM that has direct access to it;
`一 partitioned: the GPU resources are split into smaller virtual GPUs, assigned
`to single VMs.
`
`Once VMs have access to the GPU, the interaction between the guest and
`the real resource can be achieved in two different ways: backend virtualization
`or frontend virtualization [17]. Backend virtualization gives a direct connection
`between the VM and the GPU hardware. Frontend virtualization poses an inter-
`mediate layer between the guest and the hardware that has to leverage some kind
`of intermediate APIs to access the GPU. Some frontend virtualization examples
`are gVirt [56], vCUDA [53], GViM [22] and VOCL [59].
`
`Table 2. GPU-related virtualization features
`
`
`
`X86_64 hypervisor | Open source | Supported GPU virtualization technologies
`
`
`
`Xen
`
`Y
`
`Intel GVT-g, AMD MxGPU
`
`
`
`KVM
`
`Y
`
`Intel GVT-g, AMD MxGPU
`
`
`
`VMWare ESX
`
`Hyper-V
`
`N
`
`N
`
`Virtualbox
`
`Y
`
`
`
`Intel GVT-g, AMD MxGPU
`
`-
`
`-
`
`
`
`
`
`
`
`
`
`Particularly relevant here is AMD MxGPU technology [58], a partitioning
`strategy allowing users to have an equal share of the GPU. This hardware-
`based virtualization solution helps guaranteeing some isolation among different
`workloads and users.
`full GPU virtualization solution with mediated
`a
`is
`Intel GVT-g [56]
`passthrough (VFIO? mediated device framework based). A virtual GPU instance
`is maintained for each VM, with part of performance critical resources directly
`assigned. The capability of running native graphics driver inside a VM, without
`hypervisor intervention in performance critical paths, achieves a good balance
`among performance, feature, and sharing capability.
`As GPUs are mainly used for computation tasks, security concerns about
`GPU virtualization are mainly focused on data leakage [16]. This can occur
`either by directly access data owned by the victim and stored within the GPU
`memory or by exploiting side channels. In [41], Christin et al. have depicted two
`adversary models:
`
`一 serial adversary: this attacker has access to the same GPU or to the same
`GPU memory of the victim, before or after the victim. Hence, it can seek for
`traces previously left by the victim in different GPU memories;
`一 parallel adversary: this attacker has access to the same GPU or GPU
`memory of the victim but in the same moment.
`
`? Virtual Function I/O.
`
`

`

`Virtualization Technologies and Cloud Security
`
`171
`
`3
`
`Virtualization Security Issues
`
`Virtualization technologies underlying Cloud computing infrastructure them-
`selves constitute vulnerable surface. In a Cloud scenario, we can observe the
`following major security challenges [35]:
`
`一 privileged user access: access to sensitive data in the Cloud has to be
`restricted to a subset of trusted users (to mitigate the risk of abuse of high
`privilege roles);
`- lack of data/computation isolation: one instance of customer data has
`to be fully isolated from data belonging to other customers;
`- reliability /availability: the Cloud provider has to setup an effective repli-
`cation and recovery mechanism to restore services, should a security issue
`occur;
`
`Virtualization potentially widens Cloud computing attack vectors such as:
`
`一 hypervisor: the hypervisor is the software element sitting in between the host
`and guests to allow mediated access to physical resources. This layer should be
`transparent to a non-privileged user running into the guest. Unfortunately,
`its presence cannot be fully hidden [46]. As such, an attacker can exploit
`hypervisor vulnerabilities to gain access to both the host system and other
`guests. Hypervisors also provide emulation capabilities for missing hardware
`elements. However, this is a potential attack surface, as demonstrated by Ray
`[47] and Geffner [26];
`一 pivoting: users can often login into specific services hosted by a VM. Once
`inside, the attacker could also exit the virtual machine she accessed, to dam-
`age the underlying physical system and/or sibling VMs.
`— migration: virtual machines can be moved over different hosts for load bal-
`ancing or disaster recovery. This “migration” is performed by copying the
`VM image over the network. An attacker can potentially eavesdrop data and
`perform a man in the middle attack if the channel is not encrypted.
`— resource allocation: virtual machines are usually executed on-demand at
`run-time, thus making the resource allocation and management process as
`dynamic as possible. Resource sharing can thwart the security of the host sys-
`tem as well as of its virtual machines. In fact, negligence in cleaning resources
`before releasing them to others can lead to severe data leakage. As an exam-
`ple, data written by a VM into volatile or persistent storage can be accessed
`by others who have access to the same elements [50];
`
`The above attacks show how virtual machines and the physical machines
`hosting them can be thwart by attackers targeting the host or just the virtual
`machine. Some mitigating approaches can be as follows:
`
`— host side: vulnerabilities in the implementation of the hypervisor can some-
`what be mitigated by frequently updating the hypervisor to reduce 0-days
`vulnerability window;
`
`

`

`172
`
`R. Di Pietro and F. Lombardi
`
`一 network monitoring: monitoring and analyzing internal communications
`between sibling guests can help; nevertheless, malicious network behavior is
`difficult to detect by means of traditional intrusion detection systems and
`intrusion prevention systems;
`一 encryption: to mitigate such migration attacks encryption of the data in
`transit can be used; nevertheless, this proves quite demanding on perfor-
`mance, and consequently on costs.
`— on allocation: this attack can be dealt with by carefully deleting/cleaning
`resources either persistent or volatile that have been previously assigned to
`other VMs;
`
`3.1
`
`Co-location Issues
`
`Co-location of virtual machines by different tenants on the same physical host is
`particularly frequent in Cloud computing. Virtual resources assigned to a tenant
`might get hacked by other virtual resources assigned to different tenants that are
`co-located within the same physical machine. Co-location can lead to different
`issues as follows:
`
`一 information leakage: by reusing the same physical hardware to allocate
`virtual resources, tenants might be able to exploit forensic tools to recover
`sensitive data from previous tenants;
`一 performance degradation: malicious tenants co-located in the same physi-
`cal host might be able to make an uneven/widely varying use of computational
`power with high cpu-intensive co-located virtual machines with the final goal
`of degrading victim’s performances;
`一 service disruption: malicious tenants sharing physical resources with their
`victim might be able to lead the hardware to unexpected behaviors thus
`causing a service disruption against the victim.
`
`A large number of research results have highlighted the actual existence of
`co-location vulnerabilities [48,61]. Such papers show that completely preventing
`tenants from sharing the same physical resources is practically unfeasible (due to
`rising costs). A viable solution [3] might be an attribute-based approach where
`tenants can express constraints over both virtual and physical resource alloca-
`tion. Tenants would be able to indicate an high data sensitivity, thus requesting
`to avoid co-location. In this way, co-location will not be allowed for virtual
`resources working on high sensitive information thus lowering the chance of data
`leakage. As a consequence, virtual resource cost would be increased. This could
`be an acceptable trade-off in most sensitive scenarios.
`
`3.2
`
`Randomness and Virtualization
`
`Cloud providers usually deploy identical VM clones when needed to satisfy
`request load. As such, it often happen that the very same images are used for
`different tenants. As a consequence, the internal random pool for clone VMs is
`
`

`

`Virtualization Technologies and Cloud Security
`
`173
`
`most probably the same/very similar for different VMs [20]. An adversary might
`exploit this weakness and try to guess the value of VM cryptographic keys [49].
`In order to address such issue, the Cloud or Service providers should try to
`increase the number of events fed to the entropy pool of VM operating systems
`as soon as they are deployed, so as to provide an adequate level of security.
`
`3.3
`
`Container Security
`
`The need for cost savings and shorter development cycles induced the succes of
`containers in the Cloud. Containers are lighter than virtual machines and provide
`near-native performance. Docker [18] is the current market leader, providing a
`fully-featured packaging tool. Nevertheless, as introduced above, Containers pro-
`vide much less isolation to applications, as such mechanisms are not based on
`hardware features but on process isolation approaches. Among other interesting
`works, Martin et al.
`[10] discuss Docker security real-world implications define
`an adversary model and describe several vulnerabilities affecting current Docker
`usage. The very same authors [40] detail Docker vulnerabilities and identify sev-
`eral vulnerabilities present by design or introduced by some original use-cases.
`Albeit some practical countermeasures are proposed, it is clear the containeriza-
`tion approach cannot guarantee an adequate level of security and protection in
`many multi-tenant scenarios.
`
`3.4
`
`Unikernel Security
`
`The container limitation in providing actual isolation can be addressed by
`Unikernels, leveraging hardware virtualization to provide a potentially better
`alternative to containers (at least from the security point of view). Unikernels
`are specialized lightweight virtual machines (VMs) that squeeze the guest oper-
`ating system and userspace layers together into one single VM layer [38]. This
`provides a smaller footprint, and a minimal attack surface. However, managing
`the privileges of thousands of unikernels is often difficult and error prone. An
`interesting approach is proposed in VirtusCap [52], a multi-layer access control
`architecture and mechanism leveraging unikernels. VirtusCap limits privileges of
`unikernels using the Principle of Least Privilege to create unikernels that have
`only the privileges they need to accomplish their task.
`
`3.5
`
`Virtualization and Spectre/Meltdown
`
`Spectre [30] and Meltdown [34] are recently discovered CPU vulnerabilities stem-
`ming from hardware-implemented performance optimizations aimed at reducing
`CPU-memory access latencies. Spectre leverages the fact that the speculative
`execution resulting from a branch misprediction may leave observable side effects
`that may reveal private data to attackers. In fact, when the memory access pat-
`tern depends on private data, the resulting state of the data cache constitutes a
`side channel an attacker can leverage to extract information about the private
`data.
`
`

`

`174
`
`R. Di Pietro and F. Lombardi
`
`Meltdown allows a userspace process to read all memory, even beyond its
`access scope. Like Spectre, the problem lies with speculative machine code exe-
`cution that allows cache-timing attacks to leak data from any existing memory
`address.
`Both Spectre and Meltdown are serious security vulnerabilities, in particular
`since they have been proven to even bypass CPU isolation features guaranteed
`by hardware-assisted virtualization. The reason why is that they are tied to
`hard-coded CPU optimizations that involve reusing (i.e. not deleting) cached
`values even though they belong to different (even security) contexts. Neverthe-
`less, Containers and Unikernels are also vulnerable. As such, mitigating such
`hardware/firmware bugs is mandatory for any kind of co-location and multi-
`tenancy of the same physical CPU.
`
`4
`
`Virtualization Benefits for Security
`
`Virtualization technologies also constitute a privileged point of view for observ-
`ing and tracing VM activity. This can be used to collect useful data, analyze
`them, and act accordingly.
`
`4.1.
`
`Virtual Machine Monitoring
`
`of requirements that a security monitoring system for the Cloud
`A core set
`should meet can be summarized as follows [35]:
`
`一 effectiveness: the system should be able to detect attacks and integrity
`violations.
`一 accuracy: the system should be able to avoid false-positives, i.e, mistakenly
`detecting malware attacks where authorized activities are taking place.
`一 transparency: the system should minimize detectability from inside guests,
`i.e., potential intruders should not be able to detect the presence of the mon-
`itoring system.
`— robustness: the host system, Cloud infrastructure and the sibling VMs
`should be protected from attacks proceeding from a compromised guest and
`it should not be possible to disable or alter the monitoring system itself.
`— reactivity: the system should either be able to take action against both the
`attempt and the compromised guest, or notify other security-management
`components.
`一 accountability: the system should not interfere with Cloud and Cloud appli-
`cation actions, but collect data and snapshots to enforce accountability poli-
`cies.
`
`Nevertheless, satisfying these requirements is quite difficult, as there is a clear
`trade-off between transparency and reactivity. Possible mitigation approaches
`include:
`
`

`

`Virtualization Technologies and Cloud Security
`
`175
`
`一 hiding reaction: i.e. leveraging regular guest maintenance actions as a reac-
`tion. E.g., halting the guest, restarting a fresh image, migrating the VM
`instance.
`一 delaying reaction: snapshotting the current status and delaying performing
`reactive activity. Nevertheless, the adversary might be able to perform further
`activity before being stopped.
`
`In fact, a viable approach to achieve integrity protection is to continuously
`monitor key components that would most probably be targeted by attacks. We
`have shown (see also [35]) that by either actively or passively monitoring kernel
`or middleware components, it
`is actually possible to detect modifications to
`kernel data and code, thus guaranteeing that kernel and middleware integrity
`have not been compromised. A fully asynchronous monitoring system can be a
`viable solution [15] to provide protection and advanced transparent introspection
`capabilities to an hypervisor, as detailed in the following.
`
`4.2
`
`Semantic Introspection and Modeling VM Behavior
`
`Monitoring key Cloud components that would be targeted or affected by attacks
`is vital in order to protect the VMs and the Cloud infrastructure [2]. By either
`actively or passively monitoring key VM components any possible modification
`to VM data and code can be traced and recorded.
`In fact, virtual machine introspection is a process that allows observing the
`state of
`a VM from outside of it. Syringe [7]
`is one example of a monitoring
`system making use of virtualization to observe and monitor guest kernel code
`integrity from a privileged VM or from the VMM. However, it
`is quite simple
`for guest code to realize it
`is running inside a VM that can potentially be a
`honeypot VM [33].
`
`
`
`APP1
`
`VM1
`
`APPn
`
`VMn
`
`
`
`
`
`|
`
`|
`
`Emulation/lsolation Layer
`
`
`
`
`
`
`
`A
`A
`
`Event Monitor and Recorder}
`“|
`
`
`
`]
`VMn Data
`VM1Data||
`[ RAT 人
`
`
`
`
`
`_/
`
`
`
`
`
`Vv
`[LC
`fetter
`
`章
`
`Hypervisor
`
`Hardware/Physical Layer
`
`|
`
`—
`
`
`
`Fig. 3. Virtualization: introspection components
`
`

`

`176
`
`R. Di Pietro and F. Lombardi
`
`is an example of advanced transparent pas-
`The approach depicted in Fig. 3
`sive tracing and recording of VM events from the hypervisor [35]. Any relevant
`event or status change is recorded by an event interceptor and it
`is then stored
`in a pool of recorder warnings where the collected information is asynchronously
`evaluated (evaluator) and, if needed, a reaction is triggered (act) according to a
`chosen policy.
`An interesting VM-introspection-based approach is CloRExPa [15], provid-
`ing various kinds of customizable resilience service solutions for Cloud guests,
`using execution path analysis. CloRExPa can trace, analyze and control live
`VM activity, and intervened code and data modifications, possibly due to either
`malicious attacks or software faults. Execution path analysis allows the VMM
`to trace the VM state and to prevent such a guest from reaching faulty states,
`leveraging scenario graphs.
`This trend towards semantic introspection of VM activity is a very active field
`also as regards mobile devices in the Cloud [27]. This is the way to go for enabling
`control over possibly untrusted mobile Cloud nodes/applications. In fact, as
`discussed above also for BYOD untrusted devices, either they have to be banned
`altogether from the enterprise or enhanced semantics-aware introspection has to
`be put in place to prevent them from leaking sensitive information. Outside of
`the enterprise, semantic introspection allows legitimate users to regain control
`over their device internals. This approach will help detect and react to malware
`and to backdoors that are put in place even by trusted software or apps.
`The main problem with introspection is that it requires knowing the internals
`and semantics of guest operating systems and running applications. This is espe-
`cially difficult in case of closed-source OS and application such as in Windows
`and Mac environments. In fact, Windows OSes have always been the main target
`of malware that have exploited numerous bugs and vulnerabilities exposed by its
`implementations [36]. Recent trusted boot technology plus additional integrity
`checks have rendered the Windows OS less vulnerable to kernel-level rootkits.
`Nevertheless, guest Windows Virtual Machines are becoming an increasingly
`interesting attack target. HyBIS [14] is the only example of introspection system
`protecting present Windows OS Guests from malware and rootkits.
`
`4.3
`
`Finer-Grained Security
`
`Some other approaches are available that can enhance a general advanced pro-
`tection system or be considered as a standalone solution.
`As an example, Cloudvisor [60] is a transparent, backward-compatible app-
`roach protecting the privacy and integrity of cloud VMs. Cloudvisor separates
`the resource management from security protection in the virtualization layer. A
`small security monitor hidden under the VMM and using nested virtualization
`[55] is leveraged to protect the VMM and VMs. This approach is claimed of not
`affecting the security of users’ data inside the VMs.
`In NestCloud [44] nested virtualization can be used in several usage models
`such as debugging and live migration. NestCloud is a three-level nested virtu-
`alization architecture minimizing the overhead caused by the additional level.
`
`

`

`Virtualization Technologies and Cloud Security
`
`177
`
`NestCloud is a very effective approach for detailed introspection of VMs at the
`cost of increased latency and reduced performance.
`Albeit not directly applied to cloud computing, Payer and Gross [45] pre-
`sented an interesting work on virtualization for safe execution of applications
`based on software-based fault isolation and policy-based system call authoriza-
`tion. A running application is encapsulated in an additional layer of protection
`using dynamic binary translation in user-space. This virtualization layer dynam-
`ically recompiles the machine code and adds multiple dynamic security guards
`that verify the running code to protect and contain the application. The binary
`translation system implemented in
`[45] redirects all system calls to a policy-
`based system call authorization framework. This interposition framework vali-
`dates every system call based on the given arguments and the location of the
`system call. Depending on the user-loadable policy and an extensible handler
`mechanism the framework decides whether a system call is allowed, rejected, or
`redirect to a specific user-space handler in the virtualization layer.
`Also Lee et al. [31] discuss how new hardware architectural features for cloud
`servers can help protect the confidentiality and integrity of a cloud customer’s
`code and data in leased Virtual Machines, even when the powerful underlying
`hypervisor may be compromised. They use a non-bypassable form of hardware
`access control leveraging the hardware trend towards manycore chips and hard-
`ware virtualization features to enhance Cloud Security. They aim at exploring
`software-hardware co-design for security to design future trustworthy systems
`that provide security protections, at the levels needed, when needed, even when
`malware is in the system.
`Another interesting work is by Cazalas et al. [8]. They study whether integrity
`of execution can be preserved for process-level virtualization protection schemes
`in the face of adversarial analysis. Their approach considers exploits that target
`the virtual execution environment itself and how it interacts with the underly-
`ing host operating system and hardware. Results indicate that such protection
`mechanisms may be vulnerable at the level where the virtualized code inter-
`acts with the underlying operating system, undermining security and calling
`for additional mitigation techniques using hardware-based integration or hybrid
`virtualization techniques that can better defend legitimate uses of virtualized
`software protection.
`
`5
`
`Secure Enclaves and Virtualization
`
`In Cloud computing environments, hardware resources are shared, and paral-
`lel computation widespread that can produce privacy and security issues when
`isolation is not enforced. In fact, the hypervisor is an important cornerstone of
`Cloud computing that is not necessarily trustworthy or bug-free. To mitigate
`this threat Intel and AMD introduced respectively SGX3 [9] and SEV* [29],
`which transparently encrypt a virtual machines memory. Intel introduced the
`
`3 Software Guard Extensions.
`4 Secure Encrypted Virtualization.
`
`

`

`178
`
`R. Di Pietro and F. Lombardi
`
`SGX [11] hardware extensions to create a trusted execution environment (secure
`enclave or isolation container) within its CPUs. SGX claims runtime protec-
`tion of a running process/VM even if the host OS and software components
`are malicious. Isolation containers are a primitive to minimize trusted software,
`leveraging trusted hardware and having a small performance overhead [11]. This
`is
`a smart idea though present implementations (AMD SEV and Intel SGX) do
`still have some limitations, as we detail in the following.
`
`5.1
`
`Intel SGX
`
`is an hardware technology aimed at protecting guest code and
`Intel SGX [54]
`data from the hypervisor. It is an architecture extension designed to increase the
`security of software through an “inverse sandbox” mechanism. Legitimate soft-
`ware can be sealed inside an “enclave” and protected from unauthorized access,
`even when malware has hypervisor privileges. SGX was designed to comply with
`some clear requirements/objectives [9]:
`
`一 protecting sensitive data from unauthorized access or modification by
`rogue software running at higher privilege levels;
`一 supporting legitimate software allowing them to continue using platform
`resources;
`一 maintaining consumer freedom allowing them to retain control of their
`platforms and the freedom to install and