CHERI Instruction-Set Architecture
Total Page：16
File Type：pdf, Size：1020Kb
Load more
Recommended publications
-
Operating Systems and Virtualisation Security Knowledge Area (Draft for Comment)
OPERATING SYSTEMS AND VIRTUALISATION SECURITY KNOWLEDGE AREA (DRAFT FOR COMMENT) AUTHOR: 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 © Crown Copyright, The National Cyber Security Centre 2019. Following wide community consultation with both academia and industry, 19 Knowledge Areas (KAs) have been identified to form the scope of the CyBOK (see diagram below). The Scope document provides an overview of these top-level KAs and the sub-topics that should be covered under each and can be found on the project website: https://www.cybok.org/. We are seeking comments within the scope of the individual KA; readers should note that important related subjects such as risk or human factors have their own knowledge areas. It should be noted that a fully-collated CyBOK document which includes issue 1.0 of all 19 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. Operating Systems and Virtualisation Security Herbert Bos Vrije Universiteit Amsterdam April 2019 INTRODUCTION In this knowledge area, we introduce the principles, primitives and practices for ensuring security at the operating system and hypervisor levels. We shall see that the challenges related to operating system security have evolved over the past few decades, even if the principles have stayed mostly the same. For instance, when few people had their own computers and most computing was done on multiuser (often mainframe-based) computer systems with limited connectivity, security was mostly focused on isolating users or classes of users from each other1. -
A VLSI Architecture for Enhancing Software Reliability Kanad Ghose Iowa State University
Iowa State University Capstones, Theses and Retrospective Theses and Dissertations Dissertations 1988 A VLSI architecture for enhancing software reliability Kanad Ghose Iowa State University Follow this and additional works at: https://lib.dr.iastate.edu/rtd Part of the Computer Sciences Commons Recommended Citation Ghose, Kanad, "A VLSI architecture for enhancing software reliability " (1988). Retrospective Theses and Dissertations. 9345. https://lib.dr.iastate.edu/rtd/9345 This Dissertation is brought to you for free and open access by the Iowa State University Capstones, Theses and Dissertations at Iowa State University Digital Repository. It has been accepted for inclusion in Retrospective Theses and Dissertations by an authorized administrator of Iowa State University Digital Repository. For more information, please contact [email protected]. INFORMATION TO USERS The most advanced technology has been used to photo graph and reproduce this manuscript from the microfilm master. UMI films the original text directly from the copy submitted. Thus, some dissertation copies are in typewriter face, while others may be from a computer printer. In the unlikely event that the author did not send UMI a complete manuscript and there are missing pages, these will be noted. Also, if unauthorized copyrighted material had to be removed, a note will indicate the deletion. Oversize materials (e.g., maps, drawings, charts) are re produced by sectioning the original, beginning at the upper left-hand comer and continuing from left to right in equal sections with small overlaps. Each oversize page is available as one exposure on a standard 35 mm slide or as a 17" x 23" black and white photographic print for an additional charge. -
FIDO Technical Glossary
Client to Authenticator Protocol (CTAP) Implementation Draft, February 27, 2018 This version: https://fidoalliance.org/specs/fido-v2.0-id-20180227/fido-client-to-authenticator-protocol-v2.0-id- 20180227.html Previous Versions: https://fidoalliance.org/specs/fido-v2.0-ps-20170927/ Issue Tracking: GitHub Editors: Christiaan Brand (Google) Alexei Czeskis (Google) Jakob Ehrensvärd (Yubico) Michael B. Jones (Microsoft) Akshay Kumar (Microsoft) Rolf Lindemann (Nok Nok Labs) Adam Powers (FIDO Alliance) Johan Verrept (VASCO Data Security) Former Editors: Matthieu Antoine (Gemalto) Vijay Bharadwaj (Microsoft) Mirko J. Ploch (SurePassID) Contributors: Jeff Hodges (PayPal) Copyright © 2018 FIDO Alliance. All Rights Reserved. Abstract This specification describes an application layer protocol for communication between a roaming authenticator and another client/platform, as well as bindings of this application protocol to a variety of transport protocols using different physical media. The application layer protocol defines requirements for such transport protocols. Each transport binding defines the details of how such transport layer connections should be set up, in a manner that meets the requirements of the application layer protocol. Table of Contents 1 Introduction 1.1 Relationship to Other Specifications 2 Conformance 3 Protocol Structure 4 Protocol Overview 5 Authenticator API 5.1 authenticatorMakeCredential (0x01) 5.2 authenticatorGetAssertion (0x02) 5.3 authenticatorGetNextAssertion (0x08) 5.3.1 Client Logic 5.4 authenticatorGetInfo (0x04) -
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. -
Privacy Engineering for Social Networks
UCAM-CL-TR-825 Technical Report ISSN 1476-2986 Number 825 Computer Laboratory Privacy engineering for social networks Jonathan Anderson December 2012 15 JJ Thomson Avenue Cambridge CB3 0FD United Kingdom phone +44 1223 763500 http://www.cl.cam.ac.uk/ c 2012 Jonathan Anderson This technical report is based on a dissertation submitted July 2012 by the author for the degree of Doctor of Philosophy to the University of Cambridge, Trinity College. 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 Privacy engineering for social networks Jonathan Anderson In this dissertation, I enumerate several privacy problems in online social net- works (OSNs) and describe a system called Footlights that addresses them. Foot- lights is a platform for distributed social applications that allows users to control the sharing of private information. It is designed to compete with the performance of today’s centralised OSNs, but it does not trust centralised infrastructure to en- force security properties. Based on several socio-technical scenarios, I extract concrete technical problems to be solved and show how the existing research literature does not solve them. Addressing these problems fully would fundamentally change users’ interactions with OSNs, providing real control over online sharing. I also demonstrate that today’s OSNs do not provide this control: both user data and the social graph are vulnerable to practical privacy attacks. Footlights’ storage substrate provides private, scalable, sharable storage using untrusted servers. Under realistic assumptions, the direct cost of operating this storage system is less than one US dollar per user-year. -
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. -
Discretionary Access Control
Part IV Access Control Confidentiality and integrity are often enforced using a form of authorization known as access control, which involves the following assumptions. • Predefined operations are the sole means by which principals can learn or update information. • A reference monitor is consulted whenever one of these predefined oper- ations is invoked; the operation is allowed to proceed only if the invoker holds the required privileges. Confidentiality then is achieved by restricting whether a given principal is au- thorized to execute operations that reveal information; integrity is achieved by restricting execution of operations that perform updates. An access control policy specifies which of the operations associated with any given object (including operations to change the policy) each given principal1 is authorized to have performed. Principals are entities to which execution can be attributed|users, processes, threads, or even procedure activations. Ob- jects are entities on which operations are defined—storage abstractions, such as memory or files (with read, write, and execute operations), and code ab- stractions, such as modules or services (with operations to initiate or suspend execution). Distinct privileges are typically associated with distinct operations, and sometimes there are distinct privileges for each different operation on each different object. So, for example, there might be a specific privilege readObj that a principal must hold to perform operation read on object Obj. The Principle of Least Privilege is best served by having fine-grained princi- pals, objects, and operations; the Principle of Failsafe Defaults favors defining an access control policy by enumerating privileges rather than prohibitions. That, however, is only a small part of the picture, and there is much ground to cover in our discussions of access control policy. -
A Capability-Based Module System for Authority Control∗†
A Capability-Based Module System for Authority Control∗† Darya Melicher1, Yangqingwei Shi2, Alex Potanin3, and Jonathan Aldrich4 1 Carnegie Mellon University, Pittsburgh, PA, USA 2 Carnegie Mellon University, Pittsburgh, PA, USA 3 Victoria University of Wellington, Wellington, New Zealand 4 Carnegie Mellon University, Pittsburgh, PA, USA Abstract The principle of least authority states that each component of the system should be given author- ity to access only the information and resources that it needs for its operation. This principle is fundamental to the secure design of software systems, as it helps to limit an application’s attack surface and to isolate vulnerabilities and faults. Unfortunately, current programming languages do not provide adequate help in controlling the authority of application modules, an issue that is particularly acute in the case of untrusted third-party extensions. In this paper, we present a language design that facilitates controlling the authority granted to each application module. The key technical novelty of our approach is that modules are first- class, statically typed capabilities. First-class modules are essentially objects, and so we formalize our module system by translation into an object calculus and prove that the core calculus is type- safe and authority-safe. Unlike prior formalizations, our work defines authority non-transitively, allowing engineers to reason about software designs that use wrappers to provide an attenuated version of a more powerful capability. Our approach allows developers to determine a module’s authority by examining the capab- ilities passed as module arguments when the module is created, or delegated to the module later during execution. -
Os Verification - a Survey As a Source of Future Challenges
International Journal of Computer Science & Engineering Survey (IJCSES) Vol.6, No.4, August 2015 OS VERIFICATION - A SURVEY AS A SOURCE OF FUTURE CHALLENGES Kushal Anjaria and Arun Mishra Department of Computer Science &Engineering, DIAT, Pune, India ABSTRACT Formal verification of an operating system kernel manifests absence of errors in the kernel and establishes trust in it. This paper evaluates various projects on operating system kernel verification and presents in- depth survey of them. The methodologies and contributions of operating system verification projects have been discussed in the present work. At the end, few unattended and interesting future challenges in operating system verification area have been discussed and possible directions towards the challenge solution have been described in brief. KEYWORDS Formal verification, operating system, kernel. 1. INTRODUCTION The security and reliability of computer system is dependent on the underlying operating system kernel; kernel is the core of operating system. The kernel provide mechanism for user level applications to access hardware, scheduling and inter-process communication. Therefore, if anything goes wrong in the kernel while programming or implementation, it will affect the operation of entire system. To ensure the correct working of a kernel, testing and/or verification techniques have been used. Testing reduces frequency of failures, while verification detects errors and eliminates failures. Consider the fragment of C code shown in figure-1 int div(int p, int q) { int r; if (p<q) r=p/q; else r=q/p; return r; } Figure1. Fragment of C code Here r being an integer, if testing has been performed with p=8, q=4 and p=16, q=32, full coverage of code can be achieved. -
The Confused Deputy Problem(Or Why Capabilities Might Have Been Invented)
The confused deputy problem(Or why capabilities might have been invented) st Berlin, 21 ,November 2014 The confused deputy | P.Jagannatha | Computer Security Seminar A very powerful program - a program that can delete all your files - a program that can scan your email for interesting tidbits. Many of us spend hours running this program. What is this program? A computer game --and every other program we use The only rights the game really needs to do its job are the ability to write in its window and to receive UI events directed at its window. Yet -- like every other program we execute -- it runs with a lot more rights than that. It runs with all of our authority. The confused deputy | P.Jagannatha | Computer Security Seminar Power is dangerous. While the game probably doesn’t do any of those things, if it became corrupted by a virus, it could The less power we give to a program, the less harm it can do when it runs. In general, giving every program we run access to all our files is dangerous, because if any of those programs get compromised, our files would be lost The solution is obvious: we should only grant a program the rights it needs to do its job, and no more. The same goes for every other application we run. The goal of object capabilities is to make that easier. The confused deputy | P.Jagannatha | Computer Security Seminar Content – Introduction – Analysis of the confused deputy problem – Examples – Ambient authority – Solution-capabilities – Advantages – D iscussion The confused deputy | P.Jagannatha | Computer Security Seminar Introduction - Deputy Client Deputy Resource Human -Confidence trick being Definitions: Application Programs that take actions on the behalf of other programs are deputies andInfrast needructur eappropriate permissions for their duties. -
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. -
Acknowledgments Preface 1 Overview I MICRO ERNEL ABSTRACTIONS
Coyotos Microkernel Specification http://coyotos.org/docs/ukernel/spec.html Coyotos Microkernel Specification Version 0.3+ March 20, 2006 Jonathan S. Shapiro, Ph.D., Eric Northup, M. Scott Doerrie, Swaroop Sridhar Systems Research Laboratory Dept. of Computer Science Johns Hopkins University Neal H. Walfield, Marcus Brinkmann GNU Hurd Project Copyright 2006, Jonathan S. Shapiro. Verbatim copies of this document may be duplicated or distributed in print or electronic form for non-commercial purposes. Legal Notice THIS SPECIFICATION IS PROVIDED ``AS IS'' WITHOUT ANY WARRANTIES, INCLUDING ANY WARRANTY OF MERCHANTABILITY, NON-INFRINGEMENT, FITNESS FOR ANY PARTICULAR PURPOSE, OR ANY WARRANTY OTHERWISE ARISING OF ANY PROPOSAL, SPECIFICATION OR SAMPLE. Table of Contents Acknowledgments Preface The Original Plan Overrun by the Hurd Coyotos: Take II A Brief Word on Terminology 1 Overview 1.1 Microkernel Objects 1.2 Sender Capabilities 1.3 Activations 1.4 Messages 1.5 Naming and Invocation 1.6 Exception and Interrupt Handling 1.7 Protection Model I MICROKERNEL ABSTRACTIONS 2 Capabilities 2.1 Representation 2.1.1 Capabilities to Memory Objects 2.1.2 Message-Related Capabilities 2.1.3 Capabilities to Processes 2.1.4 Miscellaneous Capabilities 2.2 Validity 2.3 Extensibility 3 Processes 3.1 State of a Process 3.2 FCRBs 3.3 Execution Model 3.3.1 Event Arrival and Run-In 3.3.2 Preemption 3.3.3 Exception Handling 1 of 38 04/10/06 11:19 Coyotos Microkernel Specification http://coyotos.org/docs/ukernel/spec.html 3.4 Event Delivery 4 Address Spaces 4.1 Memory