New version page

Berkeley COMPSCI 258 - Lighthouse: Hardware Support for Enforcing Information Flow Control on ManyCore Systems

Documents in this Course
Load more
Upgrade to remove ads

This preview shows page 1-2-3 out of 10 pages.

Save
View Full Document
Premium Document
Do you want full access? Go Premium and unlock all 10 pages.
Access to all documents
Download any document
Ad free experience
Premium Document
Do you want full access? Go Premium and unlock all 10 pages.
Access to all documents
Download any document
Ad free experience
Premium Document
Do you want full access? Go Premium and unlock all 10 pages.
Access to all documents
Download any document
Ad free experience

Upgrade to remove ads
Unformatted text preview:

Lighthouse: Hardware Support for Enforcing Information Flow Control on ManyCore Systems Sarah Bird University of California at Berkeley [email protected] David McGrogan University of California at Berkeley [email protected] ABSTRACT We present Lighthouse, a novel multiprocessor architecture based on restricting the flow of information in a shared memory environment. Lighthouse assigns labels corresponding to sets of taint levels to all threads, data, and other system objects, pairs of which are compared to determine the ways in which information may flow between the two corresponding objects. Lighthouse provides hardware acceleration of many common label-interaction primitives, preventing some of the performance loss that has historically accompanied information flow control systems. The use of Lighthouse's features in an actual OS would prevent many common IT problems and supply new possibilities for debugging and other applications. Categories and Subject Descriptors D.4.6 [Operating Systems] Security and Protection - Information Flow Controls General Terms Performance, Design, Security, Verification. Keywords Information Flow Control, Memory Protection, Manycore, Hardware tagging, Security 1. INTRODUCTION 1.1 Security Issues Many notorious issues in modern computing – viruses, data theft, and more – stem from vulnerabilities existing in software. These vulnerabilities are distributed over many millions of lines of code. Even if we were to restrict our concerns to a single program, ensuring that any nontrivial piece of software is free of potential security violations is very expensive in money and manpower, assuming it is possible at all; many programs and operating systems rely on third-party drivers or plug-ins to implement some functions, and these cannot be guaranteed safe by the primary program. Additionally, many of the programs available on the Internet have essentially no credentials whatsoever, and it is up to the user to decide whether to risk using them. Rather than attempting to verify the safety of every line of code manually, some projects seek to isolate all security-critical aspects from the remainder of the system, enabling security to be verified more easily if still manually. However, standard operating systems are not equipped to place insurmountable limits on the flow of data between processes or to the outside world. 1.2 Parallel Projects have been undertaken to create operating systems capable of enforcing the required data-flow isolation. Several such operating systems have indeed been created, but their need to manage permissions for all data using software-only mechanisms causes them to suffer a significant hit to performance. In order for a data-flow restricting system to maintain the level of performance users have come to expect, hardware acceleration of the security functions must be supplied. An additional condition on the nature of such a system is the ascendance of multiprocessing as the dominant hardware paradigm; the new hardware must be designed to support many processors at once. Up to this point all work in data-flow acceleration has been in a uniprocessor context. We have designed a shared-memory architecture that includes all functionality necessary for a hardware-accelerated secure OS. 1.3 Paper Overview This paper will discuss the relevant work done by others in section 2, explain the goals we set for our design in section 3, lay out the sections and operation of the actual Lighthouse architecture in section 4, convey the results of our experimental and theoretical evaluation of Lighthouse in section 5, present a variety of alternate uses for the labeling architecture in section 6, mention some limitations of Lighthouse's structure in section 7, speculate about potential future efforts and improvements in section 8, and finally give our conclusions in section 9. 2. RELATED WORK To address the security issues described in the introduction, there have generally been two different approaches used by prior research: information flow control/taint tracking orfine-grained memory protection. Our system is an attempt to merge the two areas and create a hybrid system, which capitalizes on the advantages of each. 2.1 Information Flow Control One of the most promising means of implementing the strict principle of least privilege required for ideal security is information flow control. This concept is based on preventing information from reaching any location it is not intended to reach, and generally involves high-level segmentation of programs into functional subunits, rather like a block diagram. These subunits are then allowed to communicate with each other and with the computer’s peripherals only in restricted, well-defined ways, preventing information from being leaked, memory from being improperly overwritten, and any number of other malfeasances. Previous efforts in data-flow-restricting OS construction include Asbestos [10], which pioneered the specific type of labeling mechanism we use, and HiStar [9], which extended Asbestos labeling to files and devices. Loki [5] is an implementation of HiStar that uses some hardware acceleration, but experiences no benefit beyond a reduction in the size of the code base that must be trusted as secure. Raksha [7] implements taint tracking in hardware. 2.2 Fine-Grained Memory Protection Fine-grained memory protection seeks to extend the page-level memory protection provided by operating systems to the level of words or bytes. Sometimes the ability to share regions of memory among processes to increase performance by avoiding data copying is also provided. Although not concerned with security to the same degree as Asbestos and its ilk, they share a need to store permissions for large amounts of data. Our efforts were partially informed by Mondrian Memory Protection [3,4] and Legba,[1] both of which exercise custom hardware to provide protection with performance. 3. DESIGN GOALS After analyzing


View Full Document
Download Lighthouse: Hardware Support for Enforcing Information Flow Control on ManyCore Systems
Our administrator received your request to download this document. We will send you the file to your email shortly.
Loading Unlocking...
Login

Join to view Lighthouse: Hardware Support for Enforcing Information Flow Control on ManyCore Systems and access 3M+ class-specific study document.

or
We will never post anything without your permission.
Don't have an account?
Sign Up

Join to view Lighthouse: Hardware Support for Enforcing Information Flow Control on ManyCore Systems 2 2 and access 3M+ class-specific study document.

or

By creating an account you agree to our Privacy Policy and Terms Of Use

Already a member?