DOCSLIB.ORG

Formal Reasoning About Capability Machines

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
Formal Reasoning About Capability Machines Formal Reasoning about Capability Machines Lau Skorstengaard PhD Dissertation Department of Computer Science Aarhus University Denmark Formal Reasoning about Capability Machines A Dissertation Presented to the Faculty of Science and Technology of Aarhus University in Partial Fulfillment of the Requirements for the PhD Degree by Lau Skorstengaard Friday 30th August, 2019 Abstract Today, computer security is often based on mitigations that make exploita- tion cumbersome or unlikely. In other words, mitigation techniques provide no security guarantee, and time and time again mitigations have been circum- vented. To stop the ongoing exploit-mitigation arms-race, we need security enforcement mechanisms that can be proven impossible to circumvent. Un- fortunately, mainstream computers have the necessary security primitives to support such enforcement mechanisms. Capability machines are computers that provide additional security primitives by replacing pointers with capa- bilities. Capabilities are unforgeable tokens of authority that must be used to access memory and other system resources. In this dissertation, we present foundational research in the field of se- cure compilation that targets capability machines. In particular, we present novel and provably secure enforcement mechanisms for control-flow and encapsulation properties of high-level programming languages – properties that all programmers rely on. The security proof demonstrates for the first time how state-of-the-art reasoning techniques for high-level programming languages can be used to reason about capability safety and secure compi- lation at the very lowest level. We also contribute new proof techniques for secure compilation proofs. In Chapter1, we introduce the concept of capabilities, show various in- stances of capabilities throughout computer science, and present and moti- vate the contents of this dissertation. In Chapter2, we present a formalisation of a capability machine with lo- cal capabilities and a calling convention that provably enforces well-bracketed control-flow (WBCF) and local-state encapsulation (LSE). We also present a notion of capability safety in terms of a logical relation. Using the logical relation, we prove correctness of program examples that interact with un- known code and rely on non-trivial control-flow for correctness. In Chapter3, we present a formalisation of a capability machine with lin- ear capabilities along with StkTokens: another calling convention provably enforcing WBCF and LSE. Via a novel proof technique called fully-abstract overlay semantics, we prove that StkTokens enforces these properties. The overlay semantics simplifies the full-abstraction proof significantly by retain- ing the language syntax and adding the desired property semantically. i Resume´ De fleste programmer er skrevet i højniveausprogrammeringssprog med ab- straktioner, der gør, at programmører ikke behøver at bekymre sig om hardwa- redetaljer. Computere kan dog ikke køre sadanne˚ programmer, hvilket løses ved at oversætte dem til et lavniveausprogrammeringssprog, som compute- ren forstar.˚ Umiddelbart lyder dette uskyldigt, men hvad sker der egentlig med højniveausabstraktionerne efter oversættelsen? Er de bibeholdt, og hvis ikke betyder det noget for sikkerheden? Svaret er, groft sagt, at abstraktioner- ne ikke er bibeholdt, og det giver anledning til sikkerhedsbrister. Eksempel- vis er buffer overflow angreb og return oriented-programming angreb baseret pa,˚ at forventede højniveauabstraktioner ikke bibeholdes efter oversættelse. Sikker oversættelse (i forskningsverdenen kendt som secure compilation) omhandler oversættelser, der bevarer sikkerhed efter oversættelse. Der er mange former for sikkerhed og ligesa˚ mange former for sikker oversættel- se. Full abstraction er en form for sikker oversættelse, der beviseligt bevarer abstraktioner - selv hvis programmet interagerer med ukendte ondsindede programmer. Dette er en meget stærk egenskab, som kun er opfyldt, hvis et oversat program handhæve˚ abstraktionerne. Der eksisterer i dag ikke nogen rigtig oversætter, som er fully abstract1. Et problem, i forhold til at lave en sikker oversættelse, er, at vores compu- tere ikke har tilstrækkelige sikkerhedsprimitiver til at handhæve˚ højniveaus- abstraktionerne. Hvis vi ønsker at have sikre computere, sa˚ bliver vi nødt til at ga˚ væk fra den traditionelle computer over til en computer med flere sikkerhedsprimitiver, men hvilken? Et bud kunne være capability machines, hvilket er computere, der udskifter pointers med capabilities. En capability er essentielt set en polet, der ikke kan blive forfalsket og som giver adgang til noget, eksempelvis at læse fra en del af hukommelsen. I denne afhandling tager vi et stort skridt mod at lave en rigtig sikker oversætter ved at vise, at capability machines kan udgøre grundlaget for sik- ker oversættelse. Vi viser, hvordan en capability machines ekstra sikkerheds- primitiver kan handhæve˚ en handfuld˚ højniveausabstraktioner. Vi giver til- med matematiske beviser for, at abstraktionerne er handhævet.˚ 1Der eksisterer oversættelser mellem legetøjsprogrammeringsprog, der beviseligt opfyl- der egenskaben. iii Acknowledgements First and foremost, I want to thank my supervisor Lars Birkedal for his guid- ance throughout my PhD studies. I am especially grateful for Lars’ words of encouragement when I was needlessly hard on my own work. I also want to extend a big thanks to Dominique Devriese for a long and fruitful collabora- tion as well as for hosting me at KU Leuven on a number of occasions. Al- though Dominique has not officially supervised me, he has provided plenty of advice and guidance. I also want to extend my gratitude to the people that helped and encour- aged me during my early studies. In particular, Jens Studsgaard deserves recognition for inspiring me to study computer science, and Olivier Danvy deserves thanks for guiding me during my bachelor and master studies and encouraging me to apply for the PhD studies. Finally, a big thanks goes to my friends and family who have supported me during my studies. I thank you all for taking an interest in my PhD project by asking questions about it whether or not you believed the answer would make sense to you. No PhD student is an island; in my case that is all thanks to you. Lau Skorstengaard, Aarhus, Friday 30th August, 2019. v Contents Abstracti Resume´ iii Acknowledgementsv Contents vii I Overview1 1 Introduction3 1.1 Capabilities.............................. 4 1.2 Capabilities in This Dissertation.................. 19 1.3 Dissertation Outline......................... 23 1.4 Future Work............................. 26 II Publications 29 2 Reasoning About a Machine with Local Capabilities 31 2.1 Introduction............................. 32 2.2 A Capability Machine with Local Capabilities.......... 35 2.3 Stack and Return Pointer Management Using Local Capabilities 39 2.4 Logical Relation........................... 46 2.5 Malloc................................. 60 2.6 Reusable macro instructions.................... 63 2.7 Reasoning about programs on a capability machine . 66 2.8 Examples............................... 71 2.9 Discussion .............................. 78 2.10 Related Work............................. 85 2.A Appendix............................... 88 vii viii Contents 3 StkTokens: Enforcing Well-Bracketed Control Flow and Stack Encapsulation Using . 101 3.1 Introduction.............................101 3.2 A Capability Machine with Sealing and Linear Capabilities . 105 3.3 Linear Stack and Return Capabilities . 113 3.4 Formulating Security with a Fully Abstract Overlay Semantics 119 3.5 Proving full abstraction.......................138 3.6 Discussion ..............................183 3.7 Related Work.............................187 3.A Appendix...............................190 Bibliography 195 Part I Overview 1 Chapter 1 Introduction Capability machines are low-level machines with built-in fine-grained ac- cess control. Capabilities are unforgeable tokens of authority that replace pointers on a capability machine; every operation on a capability machine is subject to a dynamic capability authority check. Capability machines have been around for decades, but recently they have seen an increased interest with the increased focus on security on computers. Security issues are often subtle, so to ensure security the enforcement must be 100% watertight. The only way to be certain that security enforcement cannot be circumvented is to formally prove it. This dissertation shows that security properties can be enforced on capability machines in a provably secure way. This dissertation is comprised of two papers that formalises two capabil- ity machines and show how they can provably enforce security properties of high-level languages. In this introduction, we provide intuition about the general notion of capabilities. The introduction is somewhat informal in its presentation whereas the papers present capability machines formally. The remainder of the introduction consists of three sections: an introduc- tion to capabilities, two ways to motivate the dissertation, and an outline of the dissertation. Capabilities exist as a concept on all abstraction layers in a computer. The introduction to capabilities, Section 1.1, contains a general capability characterisation that fits the concept of capability found on every layer. Section 1.1 also presents capabilities on different abstraction layers. Specifically, the section presents capability machines, operating system ca- pabilities,
Load more

Recommended publications
  • Capabilities
    CS 261, Fall 2015 Scribe notes September 8: Capabilities Scribe: Riyaz Faizullabhoy 1 Motivation for Capabilities In The Confused Deputy, the compiler had two sets of rights: one from the user to access user files such as source code to compile, and another set granted to the compiler intended to access a special statistics file that would collect information about language feature usage. The compiler was installed in the SYSX directory, where it was granted access to write to any file in this directory. Naturally, the statistics file SYSX/STAT was also located in this directory such that the compiler (SYSX/FORT) could add language feature information. To achieve this, the compiler's privileges were set with a home files license that was allowed by the operating system to write to any file in the SYSX directory. A billing information file SYSX/BILL was also stored in SYSX { due to its sensitive nature, this billing file was not directly accessible to users. However, since the compiler was granted access to the entire SYSX directory, users could subvert their access restrictions on the billing information file by using the compiler like so: SYSX/FORT foo.f -o SYSX/BILL The above user-invoked command to the compiler would allow the compiler to first read the user's source code in foo.f, but then the compiler's privilege to SYSX would cause the SYSX/BILL file to be overwritten with the user's binary. In effect, the compiler is the confused deputy having to reconcile both its own and the user's set of privileges, but unfortunately allows for unintended behavior.
    [Show full text]
  • Operating Systems & Virtualisation Security Knowledge Area
    Operating Systems & Virtualisation Security Knowledge Area Issue 1.0 Herbert Bos Vrije Universiteit Amsterdam EDITOR Andrew Martin Oxford University REVIEWERS Chris Dalton Hewlett Packard David Lie University of Toronto Gernot Heiser University of New South Wales Mathias Payer École Polytechnique Fédérale de Lausanne The Cyber Security Body Of Knowledge www.cybok.org COPYRIGHT © Crown Copyright, The National Cyber Security Centre 2019. This information is licensed under the Open Government Licence v3.0. To view this licence, visit: http://www.nationalarchives.gov.uk/doc/open-government-licence/ When you use this information under the Open Government Licence, you should include the following attribution: CyBOK © Crown Copyright, The National Cyber Security Centre 2018, li- censed under the Open Government Licence: http://www.nationalarchives.gov.uk/doc/open- government-licence/. The CyBOK project would like to understand how the CyBOK is being used and its uptake. The project would like organisations using, or intending to use, CyBOK for the purposes of education, training, course development, professional development etc. to contact it at con- [email protected] to let the project know how they are using CyBOK. Issue 1.0 is a stable public release of the Operating Systems & Virtualisation Security Knowl- edge Area. However, it should be noted that a fully-collated CyBOK document which includes all of the Knowledge Areas is anticipated to be released by the end of July 2019. This will likely include updated page layout and formatting of the individual Knowledge Areas KA Operating Systems & Virtualisation Security j October 2019 Page 1 The Cyber Security Body Of Knowledge www.cybok.org INTRODUCTION In this Knowledge Area, we introduce the principles, primitives and practices for ensuring se- curity at the operating system and hypervisor levels.
    [Show full text]
  • Runtime Data Driven Partitioning of Linux Code
    This is the author's version of an article that has been published in this journal. Changes were made to this version by the publisher prior to publication. The final version of record is available at http://dx.doi.org/10.1109/TDSC.2017.2745574 1 How to Fillet a Penguin: Runtime Data Driven Partitioning of Linux Code Oliver Schwahn, Stefan Winter, Nicolas Coppik, and Neeraj Suri Abstract—In many modern operating systems (OSs), there exists no isolation between different kernel components, i.e., the failure of one component can affect the whole kernel. While microkernel OSs introduce address space separation for large parts of the OS, their improved fault isolation comes at the cost of performance. Despite significant improvements in modern microkernels, monolithic OSs like Linux are still prevalent in many systems. To achieve fault isolation in addition to high performance and code reuse in these systems, approaches to move only fractions of kernel code into user mode have been proposed. These approaches solely rely on static code analyses for deciding which code to isolate, neglecting dynamic properties like invocation frequencies. We propose to augment static code analyses with runtime data to achieve better estimates of dynamic properties for common case operation. We assess the impact of runtime data on the decision what code to isolate and the impact of that decision on the performance of such “microkernelized” systems. We extend an existing tool chain to implement automated code partitioning for existing monolithic kernel code and validate our approach in a case study of two widely used Linux device drivers and a file system.
    [Show full text]
  • Capsicum Slides
    Capsicum Capability-Based Sandboxing David Drysdale Google UK Features Current LXC uses the following kernel features to contain processes: ● Kernel namespaces (ipc, uts, mount, pid, network and user) ● Apparmor and SELinux profiles ● Seccomp policies ● Chroots (using pivot_root) ● Kernel capabilities ● CGroups (control groups) Agenda ● Ideas ○ Privilege Separation ○ Capabilities ● Capsicum ○ Hybrid with POSIX ○ Application changes ● Linux container features ● Status/Outlook Check Your Privileges ● Drop unnecessary privileges ○ Just because a process starts as root, doesn't have to stay that way Check Your Privileges ● Drop unnecessary privileges ○ Just because a process starts as root, doesn't have to stay that way ● Divide up software according to what privileges are needed ○ E.g. separate media processing from credentials processing Check Your Privileges ● Drop unnecessary privileges ○ Just because a process starts as root, doesn't have to stay that way ● Divide up software according to what privileges are needed ○ E.g. separate media processing from credentials processing ● Examples: ○ OpenSSH: credential checking process ○ Chrome: renderer processes ● Design impact: ○ Do privileged operations first ○ Pass resources down a privilege gradient Capability-Based Security ● Make the privileges that a process holds more explicit Capability-Based Security ● Make the privileges that a process holds more explicit ● Access objects via unforgeable token: the capability ○ Identifies the object ○ Accompanying rights give allowed operations ○ Can only reduce, not increase rights ○ Can pass capabilities around Capability-Based Security ● Make the privileges that a process holds more explicit ● Access objects via unforgeable token: the capability ○ Identifies the object ○ Accompanying rights give allowed operations ○ Can only reduce, not increase rights ○ Can pass capabilities around ● Remove other ways of accessing objects ○ No access by name, i.e.
    [Show full text]
  • Semperos: a Distributed Capability System
    SemperOS: A Distributed Capability System Matthias Hille† Nils Asmussen† ∗ Pramod Bhatotia‡ Hermann Härtig† ∗ †Technische Universität Dresden ‡The University of Edinburgh ∗ Barkhausen Institut Abstract systems have received renewed attention recently to provide Capabilities provide an efficient and secure mechanism for an efficient and secure mechanism for resource management fine-grained resource management and protection. However, in modern hardware architectures [5, 24, 30, 36, 44, 64, 67]. as the modern hardware architectures continue to evolve Today the main improvements in compute capacity with large numbers of non-coherent and heterogeneous cores, are achieved by either adding more cores or integrating we focus on the following research question: can capability accelerators into the system. However, the increasing core systems scale to modern hardware architectures? counts exacerbate the hardware complexity required for global In this work, we present a scalable capability system to drive cache coherence. While on-chip cache coherence is likely to future systems with many non-coherent heterogeneous cores. remain a feature of future hardware architectures [45], we see More specifically, we have designed a distributed capability characteristics of distributed systems added to the hardware system based on a HW/SW co-designed capability system. by giving up on global cache coherence across a whole We analyzed the pitfalls of distributed capability operations machine [6, 28]. Additionally, various kinds of accelerators running concurrently and built the protocols in accordance are added like the Xeon Phi Processor, the Matrix-2000 accel- with the insights. We have incorporated these distributed erator, GPUs, FPGAs, or ASICs, which are used in numerous capability management protocols in a new microkernel-based application fields [4,21,32,34,43,60].
    [Show full text]
  • Improvement of the Virtualization Support in the Fiasco.OC Microkernel
    Technische Universität Berlin Master’s Thesis Chair for Security in Telecommunications (SecT) School IV — Electrical Engineering and Computer Science Technische Universität Berlin Improving Virtualization Support in the Fiasco.OC Microkernel Author: Julius Werner (#310341) Major: Computer Science (Informatik) Email: [email protected] Primary Advisor: Prof. Dr. Jean-Pierre Seifert Secondary Advisor: Prof. Dr. Hans-Ulrich Heiß Tutor: Dipl.-Inf. Matthias Lange April – August 2012 Abstract This thesis aims to improve the memory virtualization efficiency of the Fiasco.OC mi- crokernel on processors with the Intel VMX hardware-assisted virtualization architecture, which is plagued by severe performance degradation. After discussing possible approaches, this goal is accomplished by implementing support for Intel’s nested paging mechanism (EPT). Fiasco.OC’s memory management system is enhanced to allow a new kind of task whose address space is stored in the EPT page attribute format while staying compati- ble with the existing shared memory mapping interface through dynamic page attribute translation. This enhancement is complemented with support for tagged TLB entries (VPIDs), independently providing another minor performance increase. The kernel’s external virtualization API and the experimental userland VMM Karma are adapted to support these changes. The final implementation is evaluated and analyzed in the context of several benchmarks, achieving near-native performance on real-world workloads while only constituting a minor increase in complexity for the microkernel. Zusammenfassung Diese Arbeit zielt darauf ab die Speichervirtualisierungseffizienz des Fiasco.OC Mikro- kerns auf Prozessoren mit der hardwareunterstützten Virtualisierungsarchitektur Intel VMX zu verbessern, welche von schweren Performanzverlusten geplagt wird. Nach der Diskussion möglicher Lösungsansätze wird dieses Ziel mit der Unterstützung von Intels Mechanismus für verschachtelte Seitentabellen (EPT) umgesetzt.
    [Show full text]
  • Capsicum on Linux
    Capsicum on Linux David Drysdale 18 Aug 2014 Linux Security Summit Capsicum ● Pragmatic application ● of object-capability principles ● to UNIX ● and Linux in particular Google Confidential and Proprietary Capability-Based Security ● All object access needs a token: the capability ○ identifies the object ○ accompanying rights give allowed operations Google Confidential and Proprietary Capability-Based Security ● All object access needs a token: the capability ○ identifies the object ○ accompanying rights give allowed operations ● Avoid object naming & ambient authority ○ Prevent confused deputy attacks ○ Acquire capabilities ■ by inheritance ■ by creation (with subset of rights) ■ by passing Google Confidential and Proprietary Capability-Based Security ● All object access needs a token: the capability ○ identifies the object ○ accompanying rights give allowed operations ● Avoid object naming & ambient authority ○ Prevent confused deputy attacks ○ Acquire capabilities ■ by inheritance ■ by creation (with subset of rights) ■ by passing ● Note: completely different than POSIX.1e capabilities Google Confidential and Proprietary Capsicum Principles ● POSIX File Descriptor Behaviour Google Confidential and Proprietary Capsicum Principles ● POSIX File Descriptor Behaviour ● Hence Capsicum: ○ file descriptors as capabilities ○ with (new) fine-grained rights ■ policy co-located with code (ENOTCAPABLE) Google Confidential and Proprietary Capsicum Principles ● POSIX File Descriptor Behaviour ● Hence Capsicum: ○ file descriptors as capabilities ○
    [Show full text]
  • INTRODUCING CAPSICUM: PRACTICAL CAPABILITIES for UNIX 9 Permitted
    APPLICATIONS ARE INCREASINGLY ROBERT N.M. WATSON, turning to privilege separation, or JONATHAN ANDERSON, BEN LAURIE, AND KRIS KENNAWAY sandboxing, to protect themselves from malicious data, but these protections are built on the weak foundation of primitives introducing such as chroot and setuid. Capsicum is a Capsicum: practical scheme that augments the UNIX security model with fine-grained capabilities and capabilities for UNIX a sandboxed capability mode, allowing Robert N.M. Watson is a PhD candidate applications to dynamically impose at the University of Cambridge Computer capability discipline on themselves. Laboratory. His PhD research is in operating system security extensibility. Prior to joining This approach lets application authors the Computer Laboratory, he was a Senior Principal Scientist at McAfee Research, now express security policies in code, ensuring SPARTA ISSO, where he directed commercial that application-level concerns such and government research and development projects in computer security, including the as Web domains map well onto robust TrustedBSD MAC Framework now used for access control in FreeBSD, Juniper Junos, Mac OS primitives. In this article we explain OS X, and Apple iOS. His research interests how Capsicum functions, compare it to include operating system security, network stack performance, and the evolving other current sandboxing technologies in software-hardware interface. Mr. Watson is also a member of the board of directors Linux, Mac OS, and Windows, and provide for the FreeBSD Foundation, a 501(c)(3) non- examples of integrating Capsicum into profit supporting development of FreeBSD, a widely used open source operating system. existing applications, from tcpdump and [email protected] gzip to the Chromium Web browser.
    [Show full text]
  • Capexec: Towards Transparently-Sandboxed Services (Extended Version)
    CapExec: Towards Transparently-Sandboxed Services (Extended Version) Mahya Soleimani Jadidi∗, Mariusz Zaborskiy, Brian Kidney∗, Jonathan Anderson∗ ∗ Department of Electrical and Computer Engineering Memorial University of Newfoundland fmsoleimanija,brian.kidney,[email protected] y Research and Development Fudo Security Inc. [email protected] Abstract—Network services are among the riskiest programs some of which require a great deal of security expertise to executed by production systems. Such services execute large apply correctly. Incorrectly applied mechanisms may lead to a quantities of complex code and process data from arbitrary false sense of security without additional effectual protection. — and untrusted — network sources, often with high levels of system privilege. It is desirable to confine system services to a What is needed, in addition to the development of effective least-privileged environment so that the potential damage from sandboxing techniques, is the development of tools to apply a malicious attacker can be limited, but existing mechanisms those techniques. for sandboxing services require invasive and system-specific code Sandboxing is applicable through different techniques at changes and are insufficient to confine broad classes of network various levels within operating systems such as system call services. Rather than sandboxing one service at a time, we propose chroot(2) [1], sandboxing features in service managers such that the best place to add sandboxing to network services is in as systemd [2], or application containers such as jail(8) [3] the service manager that starts those services. As a first step or docker [4]. We believe that a great deal of benefit can towards this vision, we propose CapExec, a process supervisor be derived from the application of sandboxing at the level that can execute a single service within a sandbox based on a of system services without requiring invasive modifications to service declaration file in which, required resources whose limited access to are supported by Caper services, are specified.
    [Show full text]
  • Arxiv:1904.12226V1 [Cs.NI] 27 Apr 2019
    The Ideal Versus the Real: Revisiting the History of Virtual Machines and Containers Allison Randal, University of Cambridge Abstract also have greater access to the host’s privileged software (kernel, operating system) than a physically distinct ma- The common perception in both academic literature and chine would have. the industry today is that virtual machines offer better se- curity, while containers offer better performance. How- Ideally, multitenant environments would offer strong ever, a detailed review of the history of these technolo- isolation of the guest from the host, and between guests gies and the current threats they face reveals a different on the same host, but reality falls short of the ideal. The story. This survey covers key developments in the evo- approaches that various implementations have taken to lution of virtual machines and containers from the 1950s isolating guests have different strengths and weaknesses. to today, with an emphasis on countering modern misper- For example, containers share a kernel with the host, ceptions with accurate historical details and providing a while virtual machines may run as a process in the host solid foundation for ongoing research into the future of operating system or a module in the host kernel, so they secure isolation for multitenant infrastructures, such as expose different attack surfaces through different code cloud and container deployments. paths in the host operating system. Fundamentally, how- ever, all existing implementations of virtual machines and containers
    [Show full text]
  • CHERI Instruction-Set Architecture
    UCAM-CL-TR-850 Technical Report ISSN 1476-2986 Number 850 Computer Laboratory Capability Hardware Enhanced RISC Instructions: CHERI Instruction-set architecture Robert N.M. Watson, Peter G. Neumann, Jonathan Woodruff, Jonathan Anderson, David Chisnall, Brooks Davis, Ben Laurie, Simon W. Moore, Steven J. Murdoch, Michael Roe April 2014 15 JJ Thomson Avenue Cambridge CB3 0FD United Kingdom phone +44 1223 763500 http://www.cl.cam.ac.uk/ c 2014 Robert N.M. Watson, Peter G. Neumann, Jonathan Woodruff, Jonathan Anderson, David Chisnall, Brooks Davis, Ben Laurie, Simon W. Moore, Steven J. Murdoch, Michael Roe SRI International is acknowledged as an additional copyright holder Technical reports published by the University of Cambridge Computer Laboratory are freely available via the Internet: http://www.cl.cam.ac.uk/techreports/ ISSN 1476-2986 Abstract This document describes the rapidly maturing design for the Capability Hardware Enhanced RISC Instructions (CHERI) Instruction-Set Architecture (ISA), which is being developed by SRI International and the University of Cambridge. The document is intended to capture our evolving architecture, as it is being refined, tested, and formally analyzed. We have now reached 70% of the time for our research and development cycle. CHERI is a hybrid capability-system architecture that combines new processor primitives with the commodity 64-bit RISC ISA enabling software to efficiently implement fine-grained memory protection and a hardware-software object-capability security model. These extensions support incrementally adoptable, high-performance, formally based, programmer-friendly un- derpinnings for fine-grained software decomposition and compartmentalization, motivated by and capable of enforcing the principle of least privilege.
    [Show full text]
  • What's Going on with Cloudabi
    SEE TEXT ONLY WHATS GOING ON WITH CloudABI? BY ED SCHOUTEN The September/October 2015 issue of FreeBSD Journal featured an article on CloudABI, an open-source project I started working on earli- er that same year. As a fair amount of time has passed since the article appeared, let’s take a look at some of the developments that have taken place in the meantime and what is being planned next. But first, a recap of what CloudABI is and what using it looks like. CLOUDABI IN THEORY A good example of dependency injection is a web server class that depends on a separate socket loudABI is a runtime for which you can object being provided to its constructor. Such a class develop POSIX-like software. CloudABI is dif- can be unit tested very easily by passing in a mock ferent from FreeBSD's native runtime in that C socket object that generates a fictive HTTP request it enforces programs to use dependency injection. and validates the web server’s response. This class is Dependency injection is a technique that is normal- also reusable, as support for different network pro- ly used in the field of object-oriented programming tocols (IPv4 vs. IPv6, TCP vs. SCTP), cryptography to make components (classes) of a program easier (TLS), rate limiting, traffic shaping, etc., can all be to test and reuse. Instead of designing classes that added as separate helper classes. The implementa- attempt to communicate with the outside world tion of the web server class itself can remain directly, you design them so that communication unchanged.
    [Show full text]