Search 250 million research papers

Hypervisor

transcript Verlag eBooks · 2024

Cited by 0

Jailhouse hypervisor

Baryshnikov Maxim · Cvut DSpace (Czech Technical University) · 2016

Tato bakalářská práce se povídá o Jailhouse hypervisoru, což je softwarový prostředek pro realizaci asymetrického multiprocesingu. V práci se popisuje základní koncepty a operační principy tohoto hypervisoru. Ukazuje se tady jak se dá naimplementovávat jednoduchou aplikaci, což má za úkol využivat High Precision Event Timer. Dal, do prostředí hypervisoru byl portovan malý operační systém (L4 Fiasco.OC), a proběhlo to úspěšně. Naposled, byl determinovan vliv sdílené paměťové hierarchie na běh programů (tj. jejích vlastnosti týkající se práci v reálném čase) v buňce hypervizoru. Pro tento účel byly navrhnuty a spouštěny benchmarky, a ty ukázali, že při výužití dvou jáder z různými běžicí programy dochazelo se ke zpomalením testujemých procesů kvůli konkurenci za sdílené paměťové zdroje. A to až o 220% v nejhorším případě.

Cited by 0Open access

The Hypervisor Advantage

Carmelo Loiacono · New Electronics · 2020

Why using a hypervisor improves the security and reliability of an untrusted system

Cited by 0

Micro-Hypervisor Applications

Amit Vasudevan · SpringerBriefs in computer science · 2019

Cited by 0

Hypervisor to go

Knermann, Christian · Fraunhofer-Publica (Fraunhofer-Gesellschaft) · 2014

S.14-18

Cited by 0

OpenVirteX: A Network Hypervisor

Ali Al‐Shabibi, Marc De Leenheer, Matteo Gerola et al. · 2014

Virtualized environments have been around for a long time, but until recently these have focused solely on compute virtualization and left the network behind. Network virtualization enables multiple tenants to share the same physical infrastructure by decoupling the physical network from the virtual network. In this paper, we introduce OpenVirteX, a Network Virtualization Platform which provides virtual Software Defined Networks (vSDNs). Each vSDN is customizable in terms of topology as well as addressing scheme. Introduction. Techniques for virtualizing network infrastructure have lagged behind that of compute resource virtualization. This has hampered the ability of operators to provide full virtualization that extends down to the network. In the ideal case, operators would be able to provide networks whose topologies, management schemes, and use cases are under the full control of their tenants. Realization of this scheme requires the ability to construct virtual networks that are not only logically isolated, but also have fully configurable topologies and properties akin to virtual machines, e.g., can be created, destroyed, snapshotted, and migrated on demand. Such a mechanism would provide operators with the ability to give a tenant the illusion that they have full control of topology, addressing, and management of the infrastructure despite sharing it with other tenants. Here we present OpenVirteX, a network hypervisor that enables operators to provide this form of network virtualization to their customers. We leverage the growing focus on Software Defined Networks (SDN) amongst infrastructure providers aiming to simplify and add flexibility to the process of provisioning networks. In specific, OpenVirteX builds on OpenFlow [1] as the SDN medium, and our experiences with FlowVisor [2] for design. Like FlowVisor, OpenVirteX functions as a proxy within the control channel, presenting OpenFlow networks to tenants, while controlling the underlying physical infrastructure via the southbound OpenFlow interface. Figure 1 depicts this architecture. By exposing OpenFlow networks, OpenVirteX allows tenants to use their own network OS (NOS) to control the network resources corresponding to their virtual network. In other words, OpenVirteX creates multiple virtual software defined networks out of one. Unlike FlowVisor, which simply slices the entire flowspace amongst the tenants, OpenVirteX provides each tenant with a fully virtualized network featuring a tenant-specified topology and a full header space. Motivation. OpenVirteX offers a pragmatic approach to meeting the requirements of both operators and tenants in increasingly common computing situations: • Cloud: OVX facilitates the migration of an enterprise to a Cloud Infrastructure. Each customer can request an exact copy of his/her physical network, with the same address scheme and topology of the current network. The level of abstraction offered by OpenVirteX creates the illusion that the Cloud physical infrastructure fits exactly the client requirements, in terms of isolation, topology and addressing scheme. • Provider: Similarly, in a WAN scenario, virtualization is essential, e.g. to allow multiple enterprises to connect their remote sites. With OVX, this could be done easily, spawning virtual networks that provide inherited traffic isolation, security, and flexibility. Moreover, with OpenVirteX, the tenant can still control how traffic is forwarded inside his network through a NOS and can apply policies (e.g. firewall, load balancer) that in a standard network are completely managed by the ISP. The remainder of this abstract describes the virtualization approach taken by OpenVirteX, and its current state. Topology Virtualization. OpenVirteX maintains internal representations of the physical and virtual networks as a collection of software switches, links, and end hosts. The physical topology representation is the basis upon which virtual networks are mapped. Tenants can request a topology by supplying a mapping between the elements in the physical topology and their desired virtual network. Virtual topologies can range from an exact copy or subset of the physical network, over a giant virtual switch that abstracts away all physical switches and links, to any custom topology as described by the tenant. The ability to control topology abstraction allows tenants to simplify their NOS, or operators to implement policies in the network. For example, a tenant may forego loop resolution in their NOS by requesting a loop-free topology, or an operator can require traffic to pass through chosen nodes by modifying the connecting path of a virtual link or between the ports of a giant switch. The mapping between virtual and physical elements are stored in a global map, but otherwise kept separate. This allows tenant networks to be reconfigured, halted, and re-initialized by simply modifying this mapping, i.e. pointing keys to different values. Finally, since virtual topologies need not correspond to the physical network, resilience can be enabled in the former Fig. 1: Network virtualization with OpenVirteX. Fig. 2: The address virtualization process. by allowing tenants to specify multiple backup paths for any virtual links between switches, or within giant switches, between ports. Address Virtualization. OpenVirteX grants tenants the ability to choose address assignments for their end hosts, allowing multiple, potentially-overlapping IP address blocks to exist in the same physical network. To differentiate hosts, OpenVirteX generates globally unique tenant IDs for each tenant, and for each host, a physical IP addresses that encodes the host’s membership using the tenant ID. Collisions of addresses are avoided by installing flow rules to rewrite addresses at the edge switches of the network, from tenant-assigned address to physical IP address at the ingress edge, and vice-versa at the egress edge. The translation process is illustrated in Figure 2. Importantly, this procedure is invisible to a tenant’s NOS or hosts, implying that a NOS used to control a virtual network created by OpenVirteX doesn’t need to be modified in any way to properly function. In addition to preventing address aliasing in a transparent way, the mapping created by the procedure is used by OpenVirteX to demultiplex northbound control messages so that they reach the correct tenant networks. Control Function Virtualization. Each virtual network may run its own NOS to program the virtual switches. OpenVirteX makes this possible by mapping various control functions for the virtual network on to the corresponding physical network resources. The translations can get complex, since an operation for one virtual switch may map onto multiple switches and links in the physical network. OpenVirteX leverages its position as proxy that allows it to intercept and manipulate the control packets before they reach their intended destination, which OpenVirteX also determines based on its virtual-physical mapping. Implementation. We have implemented a preliminary version of OpenVirteX in Java. This version currently supports OpenFlow 1.0, and supports the creation of custom topologies under overlapping IP address spaces, the ability to start and stop virtual networks and their components, and persistent storage using Mongo DB. Backup paths for resilient links and giant switches can be manually configured, or automatically generated with a simple SPF algorithm. A JSONRPC API is provided to enable configuration and monitoring of both tenant and infrastructure networks. This API has been used for an implementation of a GUI, as well as a topology embedder that generates virtual-physical mappings as configurations to OpenVirteX. Currently on-going work includes the addition of features such as virtual network snapshotting and migration, dynamic configuration of virtual networks, and external and inter-tenant connectivity. In the future topics such as HA and scalability may be explored.

Cited by 47

Hypervisor-based intrusion detection

Lionel Litty · TSpace · 2005

Unauthorized access by intruders to computer systems is a pervasive and seemingly worsening problem. This research explores the implementation of the Intrusion Sensing and Introspection System (ISIS). ISIS is an Intrusion Detection System (IDS) implemented in a hypervisor, which gives it the advantage of good visibility of events occurring in the operating system but also isolates it from the operating system so that if the operating system is compromised, the attacker cannot tamper with ISIS. ISIS uses this isolation to increase detection accuracy by watching for the symptoms of a successful attack rather than the attack itself. We introduce a symptom called a primary backdoor, which is the first interactive session that an intruder gains after a successful attack. In experiments with various exploits, as well as honeypot machines placed on the Internet, we were able to achieve detection of a variety of different attacks with very few false positives.

Cited by 18Open access

Terroir—The Hypervisor Press

Peter Brantley · Journal of Electronic Publishing · 2010

Cited by 0Open access

Hypervisor-assisted usage control

Moucha, Cornelius · Publikationsdatenbank der Fraunhofer-Gesellschaft (Fraunhofer-Gesellschaft) · 2011

Computer systems play an increasingly prominent role in our daily lives. Interacting with these systems in general and especially with services in the internet often involves the disclosing of data, like credit card information, social security numbers and tax information. Although immense work was done in the security area, many security problems are still unresolved. Usage control is an extension of access control that not only addresses who may access which data, but also what may or may not happen with the data afterwards. With the concept of monitors at di erent layers of abstraction observing events in the consumer's system and enforcing policies related to the future usage of the data, this issue can be handled. This work describes a necessary communication infrastructure for connection independently operating usage control monitors. Providing a bus system apart the consumer's operating system using virtualization technologies, an efficient and secure solution for the message exchange is designed and implemented. For the contribution required concepts and techniques are presented followed by a comparison of several existing virtualization environments with respect to their extendibility for the required communication framework. Thereafter the design and implementation of the software is discussed. Additionally a flexible communication protocol is specified allowing easy extensions for future demands. Finally the contributed solution is evaluated with respect to performance and security aspects.

Cited by 0

Building the Hypervisor Host

Kenneth/Stephen Barrett/Norris · Apress eBooks · 2014

Once the use case and requirements for your virtualized system environment have been specified (Chapter 2), you have to design the networking scheme, implement the storage configuration, and install and configure the Linux operating system.

Cited by 1

Qué es el hypervisor

Alejandro Vega Velasco · 2004

Documento HTML. Cuenta con 1 pagina en texto a blanco y negro Se encuentra dividido en conceptos.

Cited by 0

Hypervisor-based background encryption

Omote, Yushi, Chubachi, Yosuke, Shinagawa, Takahiro et al. · Future University Hakodate Academic Archive (Future University Hakodate) · 2016

Cited by 0Open access

HelenOS as Xen hypervisor

Jan Dolejš · Digital Repository (National Repository of Grey Literature) · 2012

The aim of the master thesis is to create a prototype implementation of the interface of the Xen hypervisor within the HelenOS operating system. The target architecture of this prototype implementation is IA-32. The result of the thesis is a port of HelenOS which can be uses to run the selected para-virtualized domain. The thesis contains a brief introduction to the methods of virtualization and describes the main differences between them. Thesis also describes the parts of the architecture of the Xen hypervisor and the HelenOS operating system, which will be modified in the prototype implementation. The most important part of this thesis is to select of the t testing domain as well as analyze and describe all changes, which were required for the do-main's operation.

Cited by 0

Hardware assisted hypervisor introspection

Jiangyong Shi, Yuexiang Yang, Chuan Yi Tang · SpringerPlus · 2016

In this paper, we introduce hypervisor introspection, an out-of-box way to monitor the execution of hypervisors. Similar to virtual machine introspection which has been proposed to protect virtual machines in an out-of-box way over the past decade, hypervisor introspection can be used to protect hypervisors which are the basis of cloud security. Virtual machine introspection tools are usually deployed either in hypervisor or in privileged virtual machines, which might also be compromised. By utilizing hardware support including nested virtualization, EPT protection and #BP, we are able to monitor all hypercalls belongs to the virtual machines of one hypervisor, include that of privileged virtual machine and even when the hypervisor is compromised. What's more, hypercall injection method is used to simulate hypercall-based attacks and evaluate the performance of our method. Experiment results show that our method can effectively detect hypercall-based attacks with some performance cost. Lastly, we discuss our furture approaches of reducing the performance cost and preventing the compromised hypervisor from detecting the existence of our introspector, in addition with some new scenarios to apply our hypervisor introspection system.

Cited by 20Open access

Hypervisor-Based Server Virtualization

Eduardo Correia · Advances in information quality and management · 2014

Cited by 9

Flexible Hypervisor Function Allocation

Andreas Blenk, Arsany Basta, Wolfgang Kellerer · 2016

c©2015 IEEE. Personal use of this material is permitted. Permission from IEEE must be obtained for all other uses, in any current or future media, including reprinting/republishing this material for advertising or promotional purposes, creating new collective works, for resale or redistribution to servers or lists, or reuse of any copyrighted component of this work in other works. HyperFlex: An SDN Virtualization Architecture with

Cited by 0

Subverting the Xen hypervisor

Rafal Wojtczuk · 2008

Abstract — This paper outlines the recent work by the author to design and develop a backdoor for machines running the Xen hypervisor. An attacker can gain backdoor control over the host by overwriting Xen code and data structures; as not a single byte in dom0 domain is modified, the detection of such a backdoor is difficult if conducted from within dom0. It is shown that it is feasible to modify device drivers and core kernel code to conveniently conduct DMA to arbitrary physical address, which allows for control over the hypervisor. Two backdoors have been implemented: one resides in the hypervisor code, the other resides in a hidden domain with artificially elevated privileges. Index Terms — computer security, Xen hypervisor, backdoor, DMA.

Cited by 105

Performance comparison of different hypervisor versions of the type-2 hypervisor VirtualBox

Borislav Đorđević, Saša Gucunja, Nenad Kraljević et al. · 2023

The focus of this paper is to make the file system performance comparison of different versions of the same hypervisor. VirtualBox was chosen as the hypervisor, while the selected versions are 6.0.24, 6.1.40 and the 7.0.4. The Filebench program was used for testing, which is a file system and storage benchmark application that enables the generation of a large number of workloads. It is very flexible and enables precise specification of the application’s behavior. CentOS7, an operating system from the Linux family, was used as the guest operating system. As for the tests themselves, they were performed for one, two and three virtual machines running simultaneously.

Cited by 4

Framework for Hypervisor in Grid

Senthil Kumar G · International Journal of Electrical and Electronics Engineering · 2014

In the recent years, the role of virtualization has become vital in the grid computing community to bridge the gap between computation resource configuration and job requirements. The venture of virtualization in the grid computing environment has set another challenge to monitor and manage the virtual machines in the grid. To solve this problem of monitoring the virtual machines we propose a Virtual Information System which will provide the complete information about the virtual parameters of the machine. This information would be better useful for Grid management system to enhance the management of virtual resources.

Cited by 1Open access

Streaming as a hypervisor service

Audun Nordal, Åge Kvalnes, Robert Pettersen et al. · 2013

Interference from resource sharing can cause unpredictable performance when virtual machines are consolidated on a single machine. We demonstrate performance problems with HTTP streaming in a virtual machine environment, even when no other virtual machines compete for network bandwidth. The paper suggests and evaluates a novel in-hypervisor data streaming service as a remedy to the performance problem. By modifying a Linux guest to exploit this new hypervisor interface, significant performance gains are experienced from a hosted Apache HTTP server.

Cited by 4