DOCSLIB.ORG

Overlay Window Management: User Interaction with Multiple Security Domains

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
Overlay Window Management: User Interaction with Multiple Security Domains TECHNISCHE UNIVERSITAT¨ DRESDEN Fakultat¨ Informatik TUD–FI04–02–Marz¨ 2004 Norman Feske and Christian Technische Berichte Helmuth Institute for System Architecture, Operating Technical Reports Systems Group ISSN 1430-211X Overlay Window Management: User interaction with multiple security domains Technische Universitat¨ Dresden Fakultat¨ Informatik D-01062 Dresden Germany URL: http://www.inf.tu-dresden.de/ Overlay Window Management: User interaction with multiple security domains Norman Feske and Christian Helmuth Abstract one physical computer system into multiple protection do- mains where each domain can be an entirely different oper- Graphical user interfaces for high-assurance systems must ating system. Hartig¨ [15] presents an overview of such ar- fulfill a range of security requirements such as pro- chitectures and emphasizes the trend of wide application of tected and reliable presentation, prevention of unautho- these techniques in system design. Virtual machines lead rized cross-domain talk, and prevention of user-input to an unmatched flexibility and availability of user applica- eavesdropping. Additionally, it is desirable to support tions. As described in [14], the latests efforts with secure legacy applications running in confined compartments. booting techniques—namely TCPA [6]—pushed the appli- Standard isolation methods such as virtual-machine mon- cation area of these approaches even further. Even though itors provide one frame buffer per security domain, where the known approaches are technically different, they have each frame buffer is managed by one legacy window sys- one drawback in common that shrinks the application area tem. This raises the question of how to safely integrate significantly. There exists virtually no model for secure multiple (legacy) window systems and protect the dis- user interaction with multiple security domains. played data while preserving the usability of modern user In this paper, we present a generic solution for the interfaces. addressed problem and discuss application scenarios of Our paper describes the Overlay Window System, a gen- deploying virtualization and sandboxing techniques com- eral mechanism for multiplexing windows of multiple dis- bined with our user-interaction model. tinct window systems into the host frame buffer. Thus, Currently available virtual machines perform user inter- each legacy window appears to the user as one correspond- action based on consoles. Traditionally, there exist two in- ing host window that can be moved and resized. To achieve terfaces for the interaction with the user: input devices and this, only slight modifications of the legacy window sys- a frame buffer display. This paradigm appears antiquated tem are required whereby, the source code does not have to regarding the modern way of user interaction with com- be available. Our implementation of an Overlay Window puter systems. Today, we expect to interact with windowed System successfully multiplexes Linux, GEM and native applications that can freely be arranged on the screen. L4 applications. Existing virtual machines do not to deal with such ap- plications but leave the window management to the virtu- alized legacy operating system. This way, the virtual frame 1 Introduction buffer, containing all windows of the legacy operating sys- tem, is presented to the user as one host window or as full The ever-increasing number of security-sensitive platforms screen (Figure 1). connected to untrusted public networks raises a high de- Once multiple instances of virtual machines come into mand of executing trusted and untrusted applications side- play, as described in the numerous application scenarios by-side on one device. For example, people store and in [13], the problem of multiplexing virtual frame buffers process private data on PDAs using trusted software and immediately arises and the full-screen approach becomes execute gadgets—downloaded from untrusted sources— unfeasible. which are potentially malicious (malware). There exist We want to integrate multiple legacy window systems plenty of options to deal with such scenarios, which fall into one user environment. Thus, we approach the follow- into two categories: ing problems: Firstly, there are operating systems that provide strong application-level isolation and protection. Prominent examples are the L4 family [18] and EROS [19]—a • The way of how windows are managed and how re- capability-based operating system. They provide a cus- draw operations are performed differs among legacy tom infrastructure to build applications, which in turn are operating systems. especially designed for these operating systems. For exam- ple, with DOpE [11, 12] and EWS [20] there exist custom • We want to integrate proprietary legacy operating sys- trusted window systems for these operating systems. The tems of which the source code is not available. common drawback of these solutions is the lack of avail- able applications. • We cannot access the internal data structures that rep- Secondly, with virtual machine monitors and sandbox- resent the user interface on the legacy operating sys- ing techniques, there exist powerful solutions to partition tem. • All properties of used virtualization and sandboxing techniques in regard to isolation and protection of se- curity domains must persist. Window layer 1 Logical representation In this paper, we present a solution for the problems men- tioned above. We can integrate any number of legacy win- Window layer 2 dow systems running on different virtual machines. The legacy window systems can even use virtual frame buffers Physical representation of different sizes and color depths. This can be achieved Virtual frame buffer Legacy window system with virtually no (or marginal) modifications of the legacy operating systems. As a proof-of-concept, we integrated three entirely different window systems—namely X11, GEM and DOpE—into one user environment while run- Windowed frame ning them inside fully isolated security domains. For this, we required no access to the GEM source code. The rest of the paper is structured as follows: In Sec- Physical frame buffer Host window system tion 2 we describe our basic mechanism to multiplex win- dow systems. It is followed by Section 3 that describes the actual implementation of our mechanism. Section 4 Figure 1: Virtual frame buffer displayed as one host win- highlights new application fields, which can be captured dow. Legacy window information are only exported as by virtual machines combined with our technique. In Sec- virtual frame buffer and the virtual machine displays the tion 5 we give an overview about related work and put our entire frame as one host window. Windows are displayed work in the context of trusted window systems. Section 6 with shadows at the logical representation level to high- concludes the paper with an outlook to future work. light the fact, that the semantics are known not only the pixel data. 2 Mechanism 2.1 Nested-window-systems approach important information on the way from the legacy win- dow system to the host representation. Since the exist- Current implementations of virtual machines virtualize (or ing interfaces—frame buffer and input devices—alone are emulate) standard hardware devices to enable guest oper- insufficient, we looked for novel ways to obtain the se- ating systems to perform I/O operations. This way, legacy mantics of legacy windows. An ideal (i. e. cooperative) operating systems reuse existing device drivers to access legacy window system for our purposes would provide virtual input devices or graphics cards, and thus, the host additional window information besides the virtual frame system. buffer. Thus, a host window system is able to manage The common technique for emulating graphics cards is legacy and host windows similarly, as it would know about to provide a virtual frame buffer to the guest. The legacy the semantics of legacy windows. This approach is com- window system renders its private window stack into the parable to remote GUI protocols (e. g., X11 or RDP), but virtual frame buffer (Figure 1). Thereby, the window sys- needs fewer high-level commands. tem translates its logical representation (e. g., window lists and window-decoration configuration) into the physical We have to tackle the problem of how to export legacy representation of pixels in the frame buffer. The physical window contents, positions, and sizes. Furthermore, the representation of the legacy system contains no semantics host window system needs to know the legacy window about the displayed information anymore, so that the logi- stacking order to present a consistent global window state cal representation is not known to the host window system. to the user. Figure 2 illustrates this idea. Therefore, established virtual machines render the virtual The generic export of window state information from ar- frame buffer into one big host window. bitrary legacy window systems is tricky, as the used data This approach has several usability drawbacks. Firstly, structures differ significantly. Keeping the two window the virtual-machine window is unhandy due to its size and stacks—legacy and host—consistent on the basis of totally pollutes the screen. Secondly, all legacy windows are on different structures appears to be infeasible. On the other the same stacking level regarding host window order. This hand, window-state changes (e. g., movement or resizing) highly restricts the flexibility of application-window place- are very easy to export. The host window system can use ment. Interaction with such nested window systems is nei- them to reconstruct the legacy window configuration on ther natural nor efficient. the host side. We call such a window system Overlay Window System 2.2 Overlay window system—hosting as it overlays distinct window stacks and thus, legacy and legacy windows host windows. The Overlay Window System tracks top (come to front), move, resize, open, and close window- The above-mentioned limitations are not caused by the state-change events, it receives from the legacy system. utilization of the virtual frame buffer but by the loss of This way, the Overlay Window System is at all times about these state changes via the view abstraction.
Load more

Recommended publications
  • How Do Fixes Become Bugs?
    How Do Fixes Become Bugs? A Comprehensive Characteristic Study on Incorrect Fixes in Commercial and Open Source Operating Systems Zuoning Yin‡, Ding Yuan‡, Yuanyuan Zhou†, Shankar Pasupathy∗, Lakshmi Bairavasundaram∗ ‡Department of Computer Science, Univ. of Illinois at Urbana-Champaign, Urbana, IL 61801, USA {zyin2, dyuan3}@cs.uiuc.edu †Department of Computer Science and Engineering, Univ. of California, San Diego, La Jolla , CA 92093, USA [email protected] ∗NetApp Inc., Sunnyvale, CA 94089, USA {pshankar, lakshmib}@netapp.com ABSTRACT Keywords: Incorrect fixes, software bugs, bug fixing, hu- Software bugs affect system reliability. When a bug is ex- man factor, testing posed in the field, developers need to fix them. Unfor- tunately, the bug-fixing process can also introduce errors, 1. INTRODUCTION which leads to buggy patches that further aggravate the damage to end users and erode software vendors’ reputa- 1.1 Motivation tion. As a man-made artifact, software suffers from various er- This paper presents a comprehensive characteristic study rors, referred to as software bugs, which cause crashes, hangs on incorrect bug-fixes from large operating system code bases or incorrect results and significantly threaten not only the including Linux, OpenSolaris, FreeBSD and also a mature reliability but also the security of computer systems. Bugs commercial OS developed and evolved over the last 12 years, are detected either during testing before release or in the investigating not only the mistake patterns during bug-fixing field by customers post-release. Once a bug is discovered, but also the possible human reasons in the development pro- developers usually need to fix it.
    [Show full text]
  • Improving the Reliability of Commodity Operating Systems
    Improving the Reliability of Commodity Operating Systems MICHAEL M. SWIFT, BRIAN N. BERSHAD, and HENRY M. LEVY University of Washington Despite decades of research in extensible operating system technology, extensions such as device drivers remain a significant cause of system failures. In Windows XP, for example, drivers account for 85% of recently reported failures. This paper describes Nooks, a reliability subsystem that seeks to greatly enhance OS reliability by isolating the OS from driver failures. The Nooks approach is practical: rather than guaranteeing complete fault tolerance through a new (and incompatible) OS or driver architecture, our goal is to prevent the vast majority of driver-caused crashes with little or no change to existing driver and system code. Nooks isolates drivers within lightweight protection domains inside the kernel address space, where hardware and software prevent them from corrupting the kernel. Nooks also tracks a driver’s use of kernel resources to facilitate automatic clean-up during recovery. To prove the viability of our approach, we implemented Nooks in the Linux operating system and used it to fault-isolate several device drivers. Our results show that Nooks offers a substantial increase in the reliability of operating systems, catching and quickly recovering from many faults that would otherwise crash the system. Under a wide range and number of fault conditions, we show that Nooks recovers automatically from 99% of the faults that otherwise cause Linux to crash. While Nooks was designed for drivers, our techniques generalize to other kernel extensions. We demonstrate this by isolating a kernel-mode file system and an in-kernel Internet service.
    [Show full text]
  • Access Control and Operating System
    Outline (may not finish in one lecture) Access Control and Operating Access Control Concepts Secure OS System Security • Matrix, ACL, Capabilities • Methods for resisting • Multi-level security (MLS) stronger attacks OS Mechanisms Assurance • Multics • Orange Book, TCSEC John Mitchell – Ring structure • Common Criteria • Amoeba • Windows 2000 – Distributed, capabilities certification • Unix Some Limitations – File system, Setuid • Information flow • Windows • Covert channels – File system, Tokens, EFS • SE Linux – Role-based, Domain type enforcement Access control Access control matrix [Lampson] Common Assumption Objects • System knows who the user is File 1 File 2 File 3 … File n – User has entered a name and password, or other info • Access requests pass through gatekeeper User 1 read write - - read – OS must be designed monitor cannot be bypassed User 2 write write write - - Reference Subjects monitor User 3 - - - read read User process ? Resource … User m read write read write read Decide whether user can apply operation to resource Two implementation concepts Capabilities Access control list (ACL) File 1 File 2 … Operating system concept • “… of the future and always will be …” • Store column of matrix User 1 read write - Examples with the resource User 2 write write - • Dennis and van Horn, MIT PDP-1 Timesharing Capability User 3 - - read • Hydra, StarOS, Intel iAPX 432, Eros, … • User holds a “ticket” for … • Amoeba: distributed, unforgeable tickets each resource User m read write write • Two variations References – store
    [Show full text]
  • Openbsd Gaming Resource
    OPENBSD GAMING RESOURCE A continually updated resource for playing video games on OpenBSD. Mr. Satterly Updated August 7, 2021 P11U17A3B8 III Title: OpenBSD Gaming Resource Author: Mr. Satterly Publisher: Mr. Satterly Date: Updated August 7, 2021 Copyright: Creative Commons Zero 1.0 Universal Email: [email protected] Website: https://MrSatterly.com/ Contents 1 Introduction1 2 Ways to play the games2 2.1 Base system........................ 2 2.2 Ports/Editors........................ 3 2.3 Ports/Emulators...................... 3 Arcade emulation..................... 4 Computer emulation................... 4 Game console emulation................. 4 Operating system emulation .............. 7 2.4 Ports/Games........................ 8 Game engines....................... 8 Interactive fiction..................... 9 2.5 Ports/Math......................... 10 2.6 Ports/Net.......................... 10 2.7 Ports/Shells ........................ 12 2.8 Ports/WWW ........................ 12 3 Notable games 14 3.1 Free games ........................ 14 A-I.............................. 14 J-R.............................. 22 S-Z.............................. 26 3.2 Non-free games...................... 31 4 Getting the games 33 4.1 Games............................ 33 5 Former ways to play games 37 6 What next? 38 Appendices 39 A Clones, models, and variants 39 Index 51 IV 1 Introduction I use this document to help organize my thoughts, files, and links on how to play games on OpenBSD. It helps me to remember what I have gone through while finding new games. The biggest reason to read or at least skim this document is because how can you search for something you do not know exists? I will show you ways to play games, what free and non-free games are available, and give links to help you get started on downloading them.
    [Show full text]
  • Research Purpose Operating Systems – a Wide Survey
    GESJ: Computer Science and Telecommunications 2010|No.3(26) ISSN 1512-1232 RESEARCH PURPOSE OPERATING SYSTEMS – A WIDE SURVEY Pinaki Chakraborty School of Computer and Systems Sciences, Jawaharlal Nehru University, New Delhi – 110067, India. E-mail: [email protected] Abstract Operating systems constitute a class of vital software. A plethora of operating systems, of different types and developed by different manufacturers over the years, are available now. This paper concentrates on research purpose operating systems because many of them have high technological significance and they have been vividly documented in the research literature. Thirty-four academic and research purpose operating systems have been briefly reviewed in this paper. It was observed that the microkernel based architecture is being used widely to design research purpose operating systems. It was also noticed that object oriented operating systems are emerging as a promising option. Hence, the paper concludes by suggesting a study of the scope of microkernel based object oriented operating systems. Keywords: Operating system, research purpose operating system, object oriented operating system, microkernel 1. Introduction An operating system is a software that manages all the resources of a computer, both hardware and software, and provides an environment in which a user can execute programs in a convenient and efficient manner [1]. However, the principles and concepts used in the operating systems were not standardized in a day. In fact, operating systems have been evolving through the years [2]. There were no operating systems in the early computers. In those systems, every program required full hardware specification to execute correctly and perform each trivial task, and its own drivers for peripheral devices like card readers and line printers.
    [Show full text]
  • How Do Fixes Become Bugs?
    How Do Fixes Become Bugs? A Comprehensive Characteristic Study on Incorrect Fixes in Commercial and Open Source Operating Systems Zuoning Yin‡, Ding Yuan‡, Yuanyuan Zhou†, Shankar Pasupathy∗, Lakshmi Bairavasundaram∗ ‡Department of Computer Science, Univ. of Illinois at Urbana-Champaign, Urbana, IL 61801, USA {zyin2, dyuan3}@cs.uiuc.edu †Department of Computer Science and Engineering, Univ. of California, San Diego, La Jolla , CA 92093, USA [email protected] ∗NetApp Inc., Sunnyvale, CA 94089, USA {pshankar, lakshmib}@netapp.com ABSTRACT Keywords: Incorrect fixes, software bugs, bug fixing, hu- Software bugs affect system reliability. When a bug is ex- man factor, testing posed in the field, developers need to fix them. Unfor- tunately, the bug-fixing process can also introduce errors, 1. INTRODUCTION which leads to buggy patches that further aggravate the damage to end users and erode software vendors’ reputa- 1.1 Motivation tion. As a man-made artifact, software suffers from various er- This paper presents a comprehensive characteristic study rors, referred to as software bugs, which cause crashes, hangs on incorrect bug-fixes from large operating system code bases or incorrect results and significantly threaten not only the including Linux, OpenSolaris, FreeBSD and also a mature reliability but also the security of computer systems. Bugs commercial OS developed and evolved over the last 12 years, are detected either during testing before release or in the investigating not only the mistake patterns during bug-fixing field by customers post-release. Once a bug is discovered, but also the possible human reasons in the development pro- developers usually need to fix it.
    [Show full text]
  • Mixed-Criticality Scheduling and Resource Sharing for High-Assurance Operating Systems
    Mixed-Criticality Scheduling and Resource Sharing for High-Assurance Operating Systems Anna Lyons Submitted in fulfilment of the requirements for the degree of Doctor of Philosophy School of Computer Science and Engineering University of New South Wales Sydney, Australia September 2018 Abstract Criticality of a software system refers to the severity of the impact of a failure. In a high-criticality system, failure risks significant loss of life or damage to the environ- ment. In a low-criticality system, failure may risk a downgrade in user-experience. As criticality of a software system increases, so too does the cost and time to develop that software: raising the criticality also raises the assurance level, with the highest levels requiring extensive, expensive, independent certification. For modern cyber-physical systems, including autonomous aircraft and other vehicles, the traditional approach of isolating systems of different criticality by using completely separate physical hardware, is no longer practical, being both restrictive and inefficient. The result is mixed-criticality systems, where software applications with different criticalities execute on the same hardware. Sufficient mechanisms are required to ascertain that software in mixed-criticality systems is sufficiently isolated, otherwise, all software on that hardware is promoted to the highest criticality level, driving up costs to impractical levels. For mixed-criticality systems to be viable, both spatial and temporal isolation are required. Current aviation standards allow for mixed-criticality systems where temporal and spatial resources are strictly and statically partitioned in time and space, allowing some improvement over fully isolated hardware. However, further improvements are not only possible, but required for future innovation in cyber-physical systems.
    [Show full text]
  • Legacy Reuse
    Faculty of Computer Science Institute for System Architecture, Operating Systems Group LEGACY REUSE CARSTEN WEINHOLD THIS LECTURE ... ■ So far ... ■ Basic microkernel concepts ■ Drivers, resource management ■ Today: ■ How to provide legacy OS personalities ■ How to reuse existing infrastructure ■ How to make applications happy TU Dresden Legacy Reuse 2 VIRTUALIZATION ■ Virtualization: ■ Reuse legacy OS + applications ■ Run applications in natural environment ■ Problem: Applications trapped in VMs ■ Different resource pools, namespaces ■ Cooperation is cumbersome (network, ...) ■ Full legacy OS in VM adds overhead ■ Multiple desktops? Bad user experience TU Dresden Legacy Reuse 3 MAKING THE CUT ■ Hardware level: Next week ■ Virtualize legacy OS on top of new OS ■ Operating System Personality: ■ Legacy OS interfaces reimplemented on top of – or ported to – new OS ■ Hybrid operating systems: Today ■ Run legacy OS virtualized … ■ … but tightly integrated with new OS TU Dresden Legacy Reuse 4 OPERATING SYSTEM PERSONALITIES TU Dresden Legacy Reuse 5 OS PERSONALITY ■ Idea: Adapt OS / application boundary ■ (Re-)Implement legacy APIs, not whole OS ■ May need to recompile application ■ Benefits: ■ Get desired application, established APIs ■ Good integration (namespaces, files, ...) ■ Smaller overhead than virtualization ■ Flexible, configurable, but more effort? TU Dresden Legacy Reuse 6 MONOLITHIC KERNELS App App Monolithic Kernel System Call Entry Ext2 VFAT IP Stack Disk Driver NIC Driver TU Dresden Legacy Reuse 7 DECOMPOSITION App App App App Monolithic
    [Show full text]
  • Kernel Architectures
    A short history of kernels n Early kernel: a library of device drivers, support for threads (QNX) Operating System Kernels n Monolithic kernels: Unix, VMS, OS 360… n Unstructured but fast… n Over time, became very large Ken Birman n Eventually, DLLs helped on size n Pure microkernels: Mach, Amoeba, Chorus… (borrowing some content from n OS as a kind of application Peter Sirokman) n Impure microkernels: Modern Windows OS n Microkernel optimized to support a single OS n VMM support for Unix on Windows and vice versa The great m-kernel debate Summary of First Paper n How big does it need to be? n The Performance of µ-Kernel-Based Systems (Hartig et al. 16th SOSP, Oct 1997) n With a m-kernel protection-boundary crossing forces us to n Evaluates the L4 microkernel as a basis for a full operating system n Change memory -map n Ports Linux to run on top of L4 and compares n Flush TLB (unless tagged) performance to native Linux and Linux running on n With a macro-kernel we lose structural the Mach microkernel protection benefits and fault-containment n Explores the extensibility of the L4 microkernel n Debate raged during early 1980’s Summary of Second Paper In perspective? n The Flux OSKit: A Substrate for Kernel and n L4 seeks to validate idea that a m-kernel Language Research (Ford et al. 16th SOSP, can support a full OS without terrible 1997) cost penalty n Describes a set of OS components designed to be used to build custom operating systems n Opened the door to architectures like the n Includes existing code simply using “glue code” Windows
    [Show full text]
  • The Nizza Secure-System Architecture
    Appears in the proceedings of CollaborateCom 2005, San Jose, CA, USA The Nizza Secure-System Architecture Hermann Härtig Michael Hohmuth Norman Feske Christian Helmuth Adam Lackorzynski Frank Mehnert Michael Peter Technische Universität Dresden Institute for System Architecture D-01062 Dresden, Germany [email protected] Abstract rely on a standard OS (including the kernel) to assure their security properties. The trusted computing bases (TCBs) of applications run- To address the conflicting requirements of complete ning on today’s commodity operating systems have become functionality and the protection of security-sensitive data, extremely large. This paper presents an architecture that researchers have devised system architectures that reduce allows to build applications with a much smaller TCB. It the system’s TCB by running kernels in untrusted mode is based on a kernelized architecture and on the reuse of in a secure compartment on top of a small security kernel; legacy software using trusted wrappers. We discuss the de- security-sensitive services run alongside the OS in isolated sign principles, the architecture and some components, and compartments of their own. This architecture is widely re- a number of usage examples. ferred to as kernelized standard OS or kernelized system. In this paper, we describe Nizza, a new kernelized- system architecture. In the design of Nizza, we set out to answer the question of how small the TCB can be made. 1 Introduction We have argued in previous work that the (hardware and software) technologies needed to build small secure-system Desktop and hand-held computers are used for many platforms have become much more mature since earlier at- functions, often in parallel, some of which are security tempts [8].
    [Show full text]
  • Separating Protection and Management in Cloud Infrastructures
    SEPARATING PROTECTION AND MANAGEMENT IN CLOUD INFRASTRUCTURES A Dissertation Presented to the Faculty of the Graduate School of Cornell University in Partial Fulfillment of the Requirements for the Degree of Doctor of Philosophy by Zhiming Shen December 2017 c 2017 Zhiming Shen ALL RIGHTS RESERVED SEPARATING PROTECTION AND MANAGEMENT IN CLOUD INFRASTRUCTURES Zhiming Shen, Ph.D. Cornell University 2017 Cloud computing infrastructures serving mutually untrusted users provide se- curity isolation to protect user computation and resources. Additionally, clouds should also support flexibility and efficiency, so that users can customize re- source management policies and optimize performance and resource utiliza- tion. However, flexibility and efficiency are typically limited due to security requirements. This dissertation investigates the question of how to offer flexi- bility and efficiency as well as strong security in cloud infrastructures. Specifically, this dissertation addresses two important platforms in cloud in- frastructures: the containers and the Infrastructure as a Service (IaaS) platforms. The containers platform supports efficient container provisioning and execut- ing, but does not provide sufficient security and flexibility. Different containers share an operating system kernel which has a large attack surface, and kernel customization is generally not allowed. The IaaS platform supports secure shar- ing of cloud resources among mutually untrusted users, but does not provide sufficient flexibility and efficiency. Many powerful management primitives en- abled by the underlying virtualization platform are hidden from users, such as live virtual machine migration and consolidation. The main contribution of this dissertation is the proposal of an approach in- spired by the exokernel architecture that can be generalized to any multi-tenant system to improve security, flexibility, and efficiency.
    [Show full text]
  • Research on Virtualisation Technlogy for Real-Time Reconfigurable Systems Tian Xia
    Research on virtualisation technlogy for real-time reconfigurable systems Tian Xia To cite this version: Tian Xia. Research on virtualisation technlogy for real-time reconfigurable systems. Electronics. INSA de Rennes, 2016. English. NNT : 2016ISAR0009. tel-01418453 HAL Id: tel-01418453 https://tel.archives-ouvertes.fr/tel-01418453 Submitted on 16 Dec 2016 HAL is a multi-disciplinary open access L’archive ouverte pluridisciplinaire HAL, est archive for the deposit and dissemination of sci- destinée au dépôt et à la diffusion de documents entific research documents, whether they are pub- scientifiques de niveau recherche, publiés ou non, lished or not. The documents may come from émanant des établissements d’enseignement et de teaching and research institutions in France or recherche français ou étrangers, des laboratoires abroad, or from public or private research centers. publics ou privés. THESE INSA Rennes présentée par sous le sceau de l’Université Bretagne Loire pour obtenir le titre de Tian Xia DOCTEUR DE L’INSA RENNES ECOLE DOCTORALE : MATISSE Spécialité : Electronique et Télécommunications LABORATOIRE : IETR Thèse soutenue le 05.07.2016 Research on devant le jury composé de : Virtualization Technology François Verdier Professeur, Université de Nice, Nice / Président for Real-time Emmanuel Grolleau Professeur, ISAE-ENSMA, Chasseneuil-Futuroscope / Rapporteur Reconfigurable Systems Guy Gogniat Professeur, Université de Bretagne-Sud, Lorient / Rapporteur Jean-Luc Bechennec Chargé de Recherche, Ecole Centrale de Nantes, Nantes / Examinateur Jean-Christophe Prévotet Maître de Conférence, INSA, Rennes / Co-encadrant de thèse Fabienne Nouvel Maître de Conférence HDR, INSA, Rennes / Directrice de thèse Research on Virtualization Technology for Real-time Reconfigurable Systems Tian Xia Résumé de la Thèse Aujourd’hui, les systèmes embarqués jouent un rôle prépondérant dans la vie quo- tidienne des utilisateurs.
    [Show full text]