DOCSLIB.ORG

Fast and Secure Inter-Process Communication for Microkernels

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
Fast and Secure Inter-Process Communication for Microkernels SkyBridge: Fast and Secure Inter-Process Communication for Microkernels Zeyu Mi, Dingji Li, Zihan Yang, Xinran Wang, Haibo Chen Shanghai Key Laboratory for Scalable Computing Systems Institute of Parallel and Distributed Systems, Shanghai Jiao Tong University Abstract ACM Reference Format: Zeyu Mi, Dingji Li, Zihan Yang, Xinran Wang, Haibo Chen. 2019. Microkernels have been extensively studied over decades. SkyBridge: Fast and Secure Inter-Process Communication for Mi- However, IPC (Inter-Process Communication) is still a ma- crokernels. In Fourteenth EuroSys Conference 2019 (EuroSys ’19), jor factor of run-time overhead, where fine-grained isolation March 25–28, 2019, Dresden, Germany. ACM, New York, NY, usually leads to excessive IPCs. The main overhead of IPC USA, 15 pages. hps://doi.org/10.1145/3302424.3303946 comes from the involvement of the kernel, which includes the direct cost of mode switches and address space changes, as well as indirect cost due to the pollution of processor struc- 1 Introduction tures. Microkernels have been extensively studied over the past In this paper, we present SkyBridge, a new communica- four decades [22, 28, 29, 36, 42, 43, 48, 60, 63]. The key tion facility designed and optimized for synchronous IPC design is to deprivilege most kernel functionalities into dif- in microkernels. SkyBridge requires no involvement of ker- ferent servers residing in isolated user processes. The ker- nels during communication and allows a process to directly nel provides basic functionalities, such as process manage- switch to the virtual address space of the target process and ment, capability enforcement and inter-process communica- invoke the target function. SkyBridge retains the traditional tion (IPC). Such a decentralized design makes the OS archi- virtual address space isolation and thus can be easily inte- tecture robust against run-time errors, which means a fault grated into existing microkernels. The key idea of SkyBridge within one server would not affect other servers and the ker- is to leverage a commodity hardware feature for virtualiza- nel. Removing most functionalities from the kernel also re- tion (i.e., VMFUNC) to achieve efficient IPC. To leverage sults in a small Trusted Computing Base (TCB), making it the hardware feature, SkyBridge inserts a tiny virtualization less vulnerable to attacks and possible for comprehensive layer (Rootkernel) beneath the original microkernel (Subker- formal verification [36]. Given such advantages, microker- nel). The Rootkernel is carefully designed to eliminate most nels [29, 34] are widely used in various areas where high re- virtualization overheads. SkyBridge also integrates a series liability matters, such as aerospace, automotive and medical of techniques to guarantee the security properties of IPC. devices. We have implemented SkyBridge on three popular open- In a microkernel, any communication between different source microkernels (seL4, Fiasco.OC, and Google Zircon). user processes is based on IPC, which is an intensively-used The evaluation results show that SkyBridge improves the operation. For example, if a client process writes data into speed of IPC by 1.49x to 19.6x for microbenchmarks. For an external block device, it first communicates with the file real-world applications (e.g., SQLite3 database), SkyBridge system, which in turn notifies the disk device driver to write improves the throughput by 81.9%, 1.44x and 9.59x for the data into the block device. All the communication is done three microkernels on average. via IPC. In fact, IPC is known as a major factor of run- time overhead [20, 27, 40, 52], which determines the per- formance of applications on microkernels. Transferring con- trol across process boundaries is expensive, which requires at least: a trap into the microkernel (SYSCALL instruction), Permission to make digital or hard copies of all or part of this work for personal or classroom use is granted without fee provided that copies are not data copying for arguments, one address space switch (even made or distributed for profit or commercial advantage and that copies bear two switches if considering the recent Meltdown attack [45]), this notice and the full citation on the first page. Copyrights for components and an upcall back to the user level. Such operations must be of this work owned by others than ACM must be honored. Abstracting with repeated upon IPC return. Some asynchronous implementa- credit is permitted. To copy otherwise, or republish, to post on servers or to tion of IPC even involves costly scheduling work. redistribute to lists, requires prior specific permission and/or a fee. Request permissions from [email protected]. A large body of research has been done to optimize the EuroSys ’19, March 25–28, 2019, Dresden, Germany IPC performance. Software-based solutions try to shorten © 2019 Association for Computing Machinery. the IPC path by removing unnecessary operations. seL4 [36] ACM ISBN 978-1-4503-6281-8/19/03. $15.00 uses the IPC fastpath for the case of Call and ReplyWait hps://doi.org/10.1145/3302424.3303946 system calls where the IPC message fits in CPU registers, 1 EuroSys ’19, March 25–28, 2019, Dresden, Germany Zeyu Mi, Dingji Li, Zihan Yang, Xinran Wang, Haibo Chen and no capabilities are transferred. For a fastpath, the mes- a tiny virtualization layer (called Rootkernel) only consist- sage will be sent immediately and the control flow will be ing of the most primitive functionalities for SkyBridge while directly transferred without entering into the costly sched- eliminating VM exits during an IPC. uling logic. Similarly, some software-based solutions like Second, existing ways [41, 46] of leveraging VMFUNC LRPC [8] also eliminate the scheduling overhead and allow require non-trivial modification to the microkernels and thus a process’s thread to execute requested procedures in the re- tremendous engineering effort. SkyBridge proposes a light- ceiver’s address space. However, all such approaches still weight method to efficiently switch virtual address spaces require the involvement of the kernel and thus their perfor- among different processes which can be easily integrated mance (around 1000 cycles for an IPC roundtrip) do not sat- into microkernel architectures. isfy the requirement of IPC-intensive workloads, as shown Third, it is difficult to design a secure IPC facility without in Section 2. Hardware-based solutions propose new hard- the involvement of the kernel, especially when one malicious ware extensions to boost IPC operation. dIPC [55] puts all process can exploit the VMFUNC instruction to corrupt IPC participants into a single address space, and the ker- other processes [46]. SkyBridge guarantees that there is only nel is removed from the IPC path. The process isolation one legal entry point for switching address spaces among is achieved by the newly designed tagged memory. Such processes, which prevents a malicious process from invok- hardware-based solutions usually require non-trivial modifi- ing self-prepared VMFUNC instructions to corrupt other pro- cation to both hardware and software, which have less poten- cesses. SkyBridge also requires a process to register to other tial for practical adoption. processes before communicating with them and introduces a Therefore, we argue that there is a need for an IPC tech- calling-key table mechanism to enforce such a policy. nique that satisfies the following requirements. We have implemented SkyBridge on three different micro- kernels (seL4 [36], Fiasco.OC [1] and Google Zircon [5]) • Efficient: the IPC path does not involve the kernel. and deployed them on a commodity Intel Skylake machine. • Lightweight: the IPC can be readily deployed on com- Our evaluation shows that SkyBridge significantly improves modity hardware and can be easily integrated into ex- the performance of IPC by 1.49x, 5.86x, and 19.6x for seL4 isting microkernel architecture. (fastpath), Fiasco.OC and Zircon respectively. For a real- • Secure: the IPC design does not break the microkernel world application like a multi-tier SQLite3 workload, Sky- isolation abstraction. Bridge improves the performance by 81.9%, 1.44x and 9.59x for such three microkernels on average. In this paper, we present a new IPC design that meets Contributions. The contributions of the paper are summa- such requirements. Our design, called SkyBridge, allows one rized as follows: process (sender) to directly execute the requested procedure in another process’s (receiver) address space without trap- • A detailed analysis of the performance overheads of ping into the kernel. SkyBridge has two main technical ad- IPC in state-of-the-art microkernels. vantages. First, SkyBridge still places each process in its • A new design which can significantly improve the per- own virtual address space which fits well with the design formance of the microkernel IPC without any modifi- and implementation of existing microkernels. Second, Sky- cation to the hardware. Bridge leverages one Intel hardware feature for virtualiza- • An implementation of SkyBridge and an evaluation us- tion, named EPT (extended page table) switching (the VM- ing real-world benchmarks on three different microker- FUNC instruction), to change the virtual address space at nels. the user level. By configuring the receiver’s EPT, SkyBridge maps the page table of the sender to that of the receiver. 2 Motivation and Background Therefore, after switching the EPT by VMFUNC, the hard- 2.1 Deconstructing Synchronous IPC ware uses the receiver’s page table to translate all subsequent virtual addresses. SkyBridge also provides a separated stack In this section, we evaluate the performance costs associ- for each receiver’s thread in its virtual address space. To sup- ated with the traditional synchronous inter-process call (IPC) port long IPC, SkyBridge provides shared buffers for the in microkernels. We use seL4 [36] (v10.0.0) on an Intel Sky- IPC participants when large messages are transferred. Each lake processor to conduct all the experiments. seL4 is known buffer is bound to one receiver’s thread for concurrency.
Load more

Recommended publications
  • Automatic Sandboxing of Unsafe Software Components in High Level Languages
    Master Thesis Automatic Sandboxing of Unsafe Software Components in High Level Languages Benjamin Lamowski Technische Universität Dresden Fakultät Informatik Institut für Systemarchitektur Professur Betriebssysteme Betreuender Hochschullehrer: Prof. Dr. rer. nat. Hermann Härtig Betreuender Mitarbeiter: Dr. Carsten Weinhold 3. Mai 2017 Aufgabenstellung Neue “sichere“ Programmiersprachen wie Go, Swift oder Rust wurden nicht nur für die normale Anwendungsentwicklung entworfen, sondern sie zielen auch auf eine hochper- formante Ausführung und Programmierung vergleichsweise systemnaher Funktionalität ab. Eine attraktive Eigenschaft beispielsweise von Rust ist das gegenüber C und C++ deutlich strengere Speicherverwaltungsmodell, bei dem bereits zur Kompilierzeit der Lebenszyklus und die Erreichbarkeit von Objekten sowie die Zuständigkeit für deren Allokation und Deallokation wohldefiniert sind. Ganze Klassen von Programmfehlern wie etwa Buffer Overflows oder Dereferenzierung ungültige Zeiger werden dadurch eliminiert und die Programme mithin sicherer und robuster. Aus diversen Gründen müssen Programme, die in sicheren Sprachen geschriebenen wurden, aber oftmals auf “unsicheren“ Legacy-Code zurückgreifen. So bietet etwa Rust über das “unsafe“-Sprachelement die Möglichkeit, Funktionen innerhalb von Bibliotheken aufzurufen, die in fehleranfälligem C geschrieben sind. Leider werden die vom Com- piler durchgesetzten Garantien der sicheren Sprache hinfällig, sobald im Code einer C-Bibliothek ein Speicherfehler auftritt. Ein Schreibzugriff etwa durch
    [Show full text]
  • A Microkernel API for Fine-Grained Decomposition
    A Microkernel API for Fine-Grained Decomposition Sebastian Reichelt Jan Stoess Frank Bellosa System Architecture Group, University of Karlsruhe, Germany freichelt,stoess,[email protected] ABSTRACT from the microkernel APIs in existence. The need, for in- Microkernel-based operating systems typically require spe- stance, to explicitly pass messages between servers, or the cial attention to issues that otherwise arise only in dis- need to set up threads and address spaces in every server for tributed systems. The resulting extra code degrades per- parallelism or protection require OS developers to adopt the formance and increases development effort, severely limiting mindset of a distributed-system programmer rather than to decomposition granularity. take advantage of their knowledge on traditional OS design. We present a new microkernel design that enables OS devel- Distributed-system paradigms, though well-understood and opers to decompose systems into very fine-grained servers. suited for physically (and, thus, coarsely) partitioned sys- We avoid the typical obstacles by defining servers as light- tems, present obstacles to the fine-grained decomposition weight, passive objects. We replace complex IPC mecha- required to exploit the benefits of microkernels: First, a nisms by a simple function-call approach, and our passive, lot of development effort must be spent into matching the module-like server model obviates the need to create threads OS structure to the architecture of the selected microkernel, in every server. Server code is compiled into small self- which also hinders porting existing code from monolithic sys- contained files, which can be loaded into the same address tems. Second, the more servers exist | a desired property space (for speed) or different address spaces (for safety).
    [Show full text]
  • A Practical UNIX Capability System
    A Practical UNIX Capability System Adam Langley <[email protected]> 22nd June 2005 ii Abstract This report seeks to document the development of a capability security system based on a Linux kernel and to follow through the implications of such a system. After defining terms, several other capability systems are discussed and found to be excellent, but to have too high a barrier to entry. This motivates the development of the above system. The capability system decomposes traditionally monolithic applications into a number of communicating actors, each of which is a separate process. Actors may only communicate using the capabilities given to them and so the impact of a vulnerability in a given actor can be reasoned about. This design pattern is demonstrated to be advantageous in terms of security, comprehensibility and mod- ularity and with an acceptable performance penality. From this, following through a few of the further avenues which present themselves is the two hours traffic of our stage. Acknowledgments I would like to thank my supervisor, Dr Kelly, for all the time he has put into cajoling and persuading me that the rest of the world might have a trick or two worth learning. Also, I’d like to thank Bryce Wilcox-O’Hearn for introducing me to capabilities many years ago. Contents 1 Introduction 1 2 Terms 3 2.1 POSIX ‘Capabilities’ . 3 2.2 Password Capabilities . 4 3 Motivations 7 3.1 Ambient Authority . 7 3.2 Confused Deputy . 8 3.3 Pervasive Testing . 8 3.4 Clear Auditing of Vulnerabilities . 9 3.5 Easy Configurability .
    [Show full text]
  • On the Construction of Reliable Device Drivers Leonid Ryzhyk
    On the Construction of Reliable Device Drivers Leonid Ryzhyk Ph.D. 2009 ii iii ‘I hereby declare that this submission is my own work and to the best of my knowledge it contains no materials previously pub- lished or written by another person, or substantial proportions of material which have been accepted for the award of any other degree or diploma at UNSW or any other educational institution, except where due acknowledgement is made in the thesis. Any contribution made to the research by others, with whom I have worked at UNSW or elsewhere, is explicitly acknowledged in the thesis. I also declare that the intellectual content of this the- sis is the product of my own work, except to the extent that as- sistance from others in the project’s design and conception or in style, presentation, and linguistic expression is acknowledged.’ Signed .................................. Date .................................. iv Abstract This dissertation is dedicated to the problem of device driver reliability. Software defects in device drivers constitute the biggest source of failure in operating systems, causing sig- nificant damage through downtime and data loss. Previous research on driver reliability has concentrated on detecting and mitigating defects in existing drivers using static analysis or runtime isolation. In contrast, this dissertation presents an approach to reducing the number of defects through an improved device driver architecture and development process. In analysing factors that contribute to driver complexity and induce errors, I show that a large proportion of errors are due to two key shortcomings in the device-driver architecture enforced by current operating systems: poorly-defined communication protocols between drivers and the operating system, which confuse developers and lead to protocol violations, and a multithreaded model of computation, which leads to numerous race conditions and deadlocks.
    [Show full text]
  • Improving Learning of Programming Through E-Learning by Using Asynchronous Virtual Pair Programming
    Improving Learning of Programming Through E-Learning by Using Asynchronous Virtual Pair Programming Abdullah Mohd ZIN Department of Industrial Computing Faculty of Information Science and Technology National University of Malaysia Bangi, MALAYSIA Sufian IDRIS Department of Computer Science Faculty of Information Science and Technology National University of Malaysia Bangi, MALAYSIA Nantha Kumar SUBRAMANIAM Open University Malaysia (OUM) Faculty of Information Technology and Multimedia Communication Kuala Lumpur, MALAYSIA ABSTRACT The problem of learning programming subjects, especially through distance learning and E-Learning, has been widely reported in literatures. Many attempts have been made to solve these problems. This has led to many new approaches in the techniques of learning of programming. One of the approaches that have been proposed is the use of virtual pair programming (VPP). Most of the studies about VPP in distance learning or e-learning environment focus on the use of the synchronous mode of collaboration between learners. Not much research have been done about asynchronous VPP. This paper describes how we have implemented VPP and a research that has been carried out to study the effectiveness of asynchronous VPP for learning of programming. In particular, this research study the effectiveness of asynchronous VPP in the learning of object-oriented programming among students at Open University Malaysia (OUM). The result of the research has shown that most of the learners have given positive feedback, indicating that they are happy with the use of asynchronous VPP. At the same time, learners did recommend some extra features that could be added in making asynchronous VPP more enjoyable. Keywords: Pair-programming; Virtual Pair-programming; Object Oriented Programming INTRODUCTION Delivering program of Information Technology through distance learning or E- Learning is indeed a very challenging task.
    [Show full text]
  • The Joe-E Language Specification (Draft)
    The Joe-E Language Specification (draft) Adrian Mettler David Wagner famettler,[email protected] February 3, 2008 Disclaimer: This is a draft version of the Joe-E specification, and is subject to change. Sections 5 - 7 mention some (but not all) of the aspects of the Joe-E language that are future work or current works in progress. 1 Introduction We describe the Joe-E language, a capability-based subset of Java intended to make it easier to build secure systems. The goal of object capability languages is to support the Principle of Least Authority (POLA), so that each object naturally receives the least privilege (i.e., least authority) needed to do its job. Thus, we hope that Joe-E will support secure programming while remaining familiar to Java programmers everywhere. 2 Goals We have several goals for the Joe-E language: • Be familiar to Java programmers. To minimize the barriers to adoption of Joe-E, the syntax and semantics of Joe-E should be familiar to Java programmers. We also want Joe-E programmers to be able to use all of their existing tools for editing, compiling, executing, debugging, profiling, and reasoning about Java code. We accomplish this by defining Joe-E as a subset of Java. In general: Subsetting Principle: Any valid Joe-E program should also be a valid Java program, with identical semantics. This preserves the semantics Java programmers will expect, which are critical to keeping the adoption costs manageable. Also, it means all of today's Java tools (IDEs, debuggers, profilers, static analyzers, theorem provers, etc.) will apply to Joe-E code.
    [Show full text]
  • Executive Summary
    Mobile Commerce Security: Legal & Technological Perspectives Michael Triguboff Table of Contents EXECUTIVE SUMMARY 4 INTRODUCTION 7 The Need for Security 11 PART I TECHNOLOGY 12 Client-Side Vulnerabilities 12 Browser Software 13 Java Applets 14 ActiveX controls 16 JavaScript 18 Plug-Ins and Graphic Files 18 Push technology 18 Web Server Security 19 Front-end 20 Firewalls 22 Back-end Database vulnerabilities 23 Server- Side Middleware 24 Operating System Problems 25 Hardened versions of Operating Systems 36 Distributed systems 37 Software Testing 38 Mobile Commerce Issues 43 Device Properties 43 Wireless Communication 45 Wireless Communication Protocols 47 Ad Hoc Networks 49 Ad Hoc Networks and Key Management 51 Network Protection in Ad Hoc Networks 54 Location Dependent Information and Mobile Computing 55 Mobile Agents 56 Protecting the Host from the Mobile Agent 59 Safe Code Interpretation 61 Digital Signatures 63 Proof Carrying Code 63 Path Histories 64 Software-Based Fault Isolation [“Sandboxing”] 64 Protecting the Agent From the Host and Other Agents 64 Secure Control of Remote Agents 65 Read-Only/Append-Only 65 Partial Results Encapsulation 66 Code Obfuscation 67 Computing with Encrypted Functions 67 Environmental Key Generation 68 Execution Tracing 68 Itinerary Recording 69 Security Through Shared Secrets and Interlocking 69 Other Approaches 69 Attacks Based on Device Limitations 71 2 Prevention, Detection and Reaction 71 Intrusion Detection 72 Intrusion Detection and Mobile Agents 75 Part I Conclusion 76 PART 11 THE LEGAL PERSPECTIVE 80 The Debate: A Confluence of Two Streams 81 Uniform Electronic Transactions Act 85 Article 2B of the Uniform Commercial Code 85 The Electronic Signatures in Global and National Commerce Act [“E-Sign Act”] 88 Jurisdiction Selection 90 Reaction- Criminal Law 96 Convention on Cyber-Crime 97 Evidentiary or Procedural Law 99 Practical Considerations 100 Part II Conclusion 101 APPENDIX 103 Digital Millennium Copyright Act 103 BIBLIOGRAPHY 107 3 EXECUTIVE SUMMARY The objectives of this project are twofold.
    [Show full text]
  • Open Ongtang-Phd-Dissertation.Pdf
    The Pennsylvania State University The Graduate School SECURING MOBILE PHONES IN THE EVOLVING MOBILE ECOSYSTEM A Dissertation in Computer Science and Engineering by Machigar Ongtang © 2010 Machigar Ongtang Submitted in Partial Fulfillment of the Requirements for the Degree of Doctor of Philosophy August 2010 The dissertation of Machigar Ongtang was reviewed and approved∗ by the following: Patrick D. McDaniel Associate Professor of Computer Science and Engineering Dissertation Advisor, Chair of Committee Thomas F. La Porta Distinguished Professor of Computer Science and Engineering Trent Jaeger Associate Professor of Computer Science and Engineering Ling Rothrock Associate Professor of Industrial and Manufacturing Engineering Raj Acharya Professor of Computer Science and Engineering Department Head ∗Signatures are on file in the Graduate School. Abstract The revolution of mobile phone industry has been altering our life and business practices over the past few decades. Driven by user demands and technological advancement, we now experience rich mobile phone applications and sophisticated cellular services ranging from mobile payment, stock trading, to social networking, vehicle tracking to in-car control. As more players joining the community, this mobile phone environment has transformed into a complex network of interacting companies, known as mobile ecosystem. Unfortunately, this opening and converging mobile ecosystem has brought in more opportunities for more attacks on mobile phones, a key element of the system. This dissertation aims to achieve mobile phone security. We reveal two main chal- lenges that we need to overcome, namely developing a clear definition of secure phones, and building security infrastructure that imposes such definition on the phones. We also identify three key elements that contribute to the fidelity of mobile phones, namely, mobile phone platforms, mobile phone applications, and mobile content.
    [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]
  • Tahoe-LAFS Documentation Release 1.X
    Tahoe-LAFS Documentation Release 1.x The Tahoe-LAFS Developers January 19, 2017 Contents 1 Welcome to Tahoe-LAFS! 3 1.1 What is Tahoe-LAFS?..........................................3 1.2 What is “provider-independent security”?................................3 1.3 Access Control..............................................4 1.4 Get Started................................................4 1.5 License..................................................4 2 Installing Tahoe-LAFS 5 2.1 First: In Case Of Trouble.........................................5 2.2 Pre-Packaged Versions..........................................5 2.3 Preliminaries...............................................5 2.4 Install the Latest Tahoe-LAFS Release.................................6 2.5 Running the tahoe executable.....................................8 2.6 Running the Self-Tests..........................................8 2.7 Common Problems............................................9 2.8 Using Tahoe-LAFS............................................9 3 How To Run Tahoe-LAFS 11 3.1 Introduction............................................... 11 3.2 Do Stuff With It............................................. 12 3.3 Socialize................................................. 13 3.4 Complain................................................. 13 4 Configuring a Tahoe-LAFS node 15 4.1 Node Types................................................ 16 4.2 Overall Node Configuration....................................... 16 4.3 Connection Management........................................
    [Show full text]
  • Capability Myths Demolished
    Capability Myths Demolished Mark S. Miller Ka-Ping Yee Jonathan Shapiro Combex, Inc. University of California, Berkeley Johns Hopkins University [email protected] [email protected] [email protected] ABSTRACT The second and third myths state false limitations on We address three common misconceptions about what capability systems can do, and have been capability-based systems: the Equivalence Myth (access propagated by a series of research publications over the control list systems and capability systems are formally past 20 years (including [2, 3, 7, 24]). They have been equivalent), the Confinement Myth (capability systems cited as reasons to avoid adopting capability models cannot enforce confinement), and the Irrevocability and have even motivated some researchers to augment Myth (capability-based access cannot be revoked). The capability systems with extra access checks [7, 13] in Equivalence Myth obscures the benefits of capabilities attempts to fix problems that do not exist. The myths as compared to access control lists, while the Confine- about what capability systems cannot do continue to ment Myth and the Irrevocability Myth lead people to spread, despite formal results [22] and practical see problems with capabilities that do not actually exist. systems [1, 9, 18, 21] demonstrating that they can do these supposedly impossible things. The prevalence of these myths is due to differing inter- pretations of the capability security model. To clear up We believe these severe misunderstandings are rooted the confusion, we examine three different models that in the fact that the term capability has come to be have been used to describe capabilities, and define a set portrayed in terms of several very different security of seven security properties that capture the distinctions models.
    [Show full text]
  • Plugging Into High-Volume Consumer Products
    ISSUE 53, SECOND QUARTER 2005ISSUE 53, SECOND QUARTER XCELL JOURNAL XILINX, INC. Issue 53 Second Quarter 2005 XcellXcelljournaljournal THETHE AUTHORITATIVEAUTHORITATIVE JOURNALJOURNAL FORFOR PROGRAMMABLEPROGRAMMABLE LOGICLOGIC USERSUSERS PluggingPlugging intointo High-VolumeHigh-Volume ConsumerConsumer ProductsProducts HIGH VOLUME Spartan-3E: A New Era Multimedia for Automotive DSP Algorithms DESIGN TOOLS New ISE 7.1i Software Control Your Designs SERIAL I/O Extend Your Reach SUBSCRIBE NOW R SEE PAGE 3 Xilinx is the only FPGA supplier in the world to have achieved high-volume 90nm production, resulting in the lowest-cost FPGAs in the industry. Our leadership in 90nm products gives you all the performance and features you need, at the lowest price points ever. Both our SpartanTM and VirtexTM product lines__ the world's most widely adopted FPGAs__ are shipping on our optimized 90nm process now. Contact your Xilinx rep today and let's ramp up for success together. The Programmable Logic CompanySM www.xilinx.com/spartan3 Pb-free devices available now ©2004 Xilinx, Inc., 2100 Logic Drive, San Jose, CA 95124. Europe +44-870-7350-600; Japan +81-3-5321-7711; Asia Pacific +852-2-424-5200; Xilinx is a registered trademark, Spartan and Virtex are trademarks, and The Programmable Logic Company is a service mark of Xilinx, Inc. LETTER FROM THE EDITOR What’s Both High and Low, and Used Everywhere...? This issue of the Xcell Journal focuses on high-volume, low-cost consumer applications and the design tools used to implement them. Business Viewpoints Our Business Viewpoints column offers an independent business perspective by Rich Wawrzyniak, Senior Analyst, ASICs Services for Semico Research Corporation.
    [Show full text]