DOCSLIB.ORG

Implicit Operating System Awareness in a Virtual Machine Monitor

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
Implicit Operating System Awareness in a Virtual Machine Monitor IMPLICIT OPERATING SYSTEM AWARENESS IN A VIRTUAL MACHINE MONITOR by Stephen T. Jones A dissertation submitted in partial fulfillment of the requirements for the degree of Doctor of Philosophy Computer Sciences at the UNIVERSITY OF WISCONSIN–MADISON 2007 For my family i ii ACKNOWLEDGMENTS So many people have contributed to the success of this endeavor. I am indebted to them all. I will mention just a few by name here. First and most importantly I want to thank my wife and best friend Alyson whose persistent faith, love, encouragement,and support have been essential to all of my successes and have helped me learn from each of my failures. She got me started on this path and has seen me through to yet another beginning. My children Emma, Abbi, and Ian provide me with constant inspiration and perspective, often when I expect it least and need it most. My advisors Andrea and Remzi gently and deftly shepherded me through the some- times uncomfortable realization of what high quality research actually is. Their curiosity and enthusiasm about computer systems and, most importantly to me, their humanity form the core of what I take away from Wisconsin. I thank my Parents Ben and Shirley Jones for giving me life, teaching me the value of work, and nurturing a loveof discoveryand learning. I also appreciate the diverse examples of all my wonderful siblings who continue to teach me whenever we are together. My brother Benjamin contributed especially to my love of design and elegant technology by generously sharing his time and ideas with me when I was young. I want to gratefully acknowledge the financial support provided to me by Sandia Na- tional Laboratories and the collective friendship and wisdom of all of my Sandia colleagues with whom I am privileged to work. My manager Roxana Jansma deserves special men- tion. She has repeatedly stepped up to provide me both material and moral support for which I am deeply grateful. The amazing technical prowess of my friend and mentor Doug Ghormley originally motivated me to return to school and I have asymmetrically benefited from his example and advice. While in Madison I have had the good fortune to interact with a fantastic group of people. Randy Smith has been a great friend with whom I have enjoyed sharing the travails and triumphs of graduate student life. My great research group colleagues Nitin Agrawal, Lakshmi Bairavasundaram, John Bent, Nathan Burnett, Tim Denehy, Haryadi Gunawi, Swetha Krishnan, Vijayan Prabhakaran, Florentina Popovici, and Muthian Sivathanu have taught me more than I ever cared to know about disk drives and storage systems. Finally, I would like to thank my many friends in the Madison first ward who have made my time in Madison a spiritual as well as an intellectual journey. iii iv Contents ABSTRACT xv 1 Introduction 1 1.1 OvercomingtheSemanticGap . 2 1.2 ResearchStatement.............................. 2 1.3 ProcessInformation.. .... .... .... ... .... .... .... 3 1.4 BufferCacheInformation. 4 1.5 SecurityApplications. 4 1.6 Contributions ................................. 5 1.7 Outline .................................... 5 2 Virtualization Background 7 2.1 TheRoleoftheVirtualMachine . 7 2.2 DeprivilegedOperation . 8 2.3 VirtualizingMemory ............................. 9 2.4 VirtualizingDiskI/O . .... .... .... ... .... .... .... 9 2.5 TrapandEmulateLimitations . 9 2.5.1 Paravirtualization. 10 2.5.2 HardwareTrends ........................... 10 2.6 Summary ................................... 10 3 Implicit Operating System Awareness 13 3.1 Goals ..................................... 13 3.2 Approach ................................... 13 3.2.1 Limitations .............................. 14 3.3 AlternativeApproaches. 14 3.3.1 NewInterfaces ............................ 15 3.3.2 ExplicitInformation . 15 3.4 Summary ................................... 16 v vi 4 Tracking Guest Operating System Processes 17 4.1 Background.................................. 18 4.1.1 x86VirtualMemoryArchitecture . 18 4.1.2 SPARCVirtualMemoryArchitecture . 19 4.2 ProcessIdentification . 19 4.2.1 Techniquesforx86 . 20 4.2.2 TechniquesforSPARC . 21 4.3 ResourceAssociation . 22 4.3.1 ContextAssociation . 22 4.3.2 EventChaining............................ 23 4.3.3 DataStructures ............................ 23 4.4 AntfarmImplementation . 24 4.4.1 AntfarmforXen ........................... 24 4.4.2 AntfarmforSimics. 24 4.5 ProcessAwarenessEvaluation . .. 25 4.5.1 x86Evaluation ............................ 25 4.5.2 Overhead ............................... 30 4.5.3 SPARCEvaluation .. .... .... ... .... .... .... 32 4.5.4 AssociationEvaluation. 35 4.5.5 EvaluationSummary . 38 4.6 CaseStudy:AnticipatoryScheduling. ..... 38 4.6.1 Background.............................. 38 4.6.2 Information.............................. 39 4.6.3 Implementation.... .... .... ... .... .... .... 39 4.6.4 Evaluation .............................. 40 4.7 Assumptions ................................. 42 4.8 Summary ................................... 43 5 Monitoring the Guest Buffer Cache 45 5.1 GeigerTechniques .............................. 46 5.1.1 BasicTechniques... .... .... ... .... .... .... 46 5.1.2 TechniquesforUnifiedCaches. 48 5.1.3 TechniquesforStorage . 49 5.2 Implementation ................................ 51 5.3 Evaluation................................... 52 5.3.1 Workloads .............................. 52 5.3.2 Metrics ................................ 53 5.3.3 Microbenchmarks .. .... .... ... .... .... .... 53 5.3.4 ApplicationBenchmarks . 55 5.3.5 Overhead ............................... 57 5.4 Casestudy:WorkingSetSizeEstimation . .... 58 5.4.1 MemRxDesign............................ 58 5.4.2 Evaluation .............................. 60 5.5 Casestudy:Eviction-BasedCachePlacement . ...... 62 vii 5.5.1 Implementation.... .... .... ... .... .... .... 63 5.5.2 Evaluation .............................. 63 5.6 Assumptions ................................. 65 5.7 Summary ................................... 66 6 Detecting and Identifying Hidden Guest Processes 67 6.1 ProcessHiding ................................ 69 6.2 Detection ................................... 70 6.2.1 Approach............................... 70 6.2.2 Details ................................ 71 6.3 Identification ................................. 72 6.3.1 Approach............................... 72 6.3.2 Details ................................ 73 6.3.3 CPUInflation............................. 74 6.4 ThreatModel ................................. 75 6.4.1 DefinitionofSuccess. 75 6.5 Evasion .................................... 75 6.6 Implementation ................................ 76 6.7 Evaluation................................... 77 6.7.1 ExperimentalEnvironment. 77 6.7.2 DetectionEvaluation . 77 6.7.3 IdentificationEvaluation . 84 6.8 AttacksonLycosid .............................. 89 6.8.1 Desynchronization . 89 6.8.2 Countermeasures ... .... .... ... .... .... .... 90 6.9 Assumptions ................................. 90 6.10Summary ................................... 91 7 RelatedWork 93 7.1 Gray-boxsystems............................... 93 7.2 GuestInformationinaVMM. 94 7.2.1 ParavirtualizationandExplicitInterfaces . ....... 94 7.2.2 ExplicitInformation . 94 7.2.3 ImplicitInformation . 95 7.3 StatisticalTechniques. .. 95 7.4 CaseStudies.................................. 95 7.4.1 WorkingSetSize ........................... 96 7.4.2 Secondary-levelCaching . 96 7.4.3 HiddenProcessDetection . 97 8 Conclusion 99 8.1 LessonsLearned ............................... 99 8.2 FutureWork..................................101 8.2.1 TargetingOtherGuestAbstractions . 101 viii 8.2.2 ResourceAssociation. .102 8.2.3 ObservingMemoryStructure . .102 8.3 ClosingRemarks ...............................103 List of Tables 4.1 Process identification techniques. The table lists the techniques used by Antfarm to detect each process event on the x86 and SPARC architectures. ......... 22 4.2 Completeness for x86. The table shows the total number of creations and exits for processes and address spaces reported by the operating system. The total number of process creations and exits inferred by Antfarm are shown in comparison. Antfarm detects all process creates and exits without false positives or false negatives on both Linux 2.4 and Windows. Fork and exec, however, lead to false positives under Linux 2.6 (bold face values). All false positives are due to the mismatch between address spaces and processes, which is indicated by matching counts for address space creates and inferred creates. Actual and inferred context switch counts are also shown for completeness and are accurate as expected. ............ 26 4.3 Completeness for SPARC. The table shows the results for the same experiments reported for x86 in Table 4.2, but for SPARC/Linux 2.4. False positives occur for each fork due to an implementation which uses copy-on-write. Antfarm also infers an additional, non-existent exit/create event pair for each exec. This error is not due to multiple address spaces per process as on x86, but rather stems from the flush that occurs to clear the caller’s address space upon exec. .......... 32 6.1 Detection Runtime Overhead. The table shows runtimes and overheads for three benchmarks run under Lycosid and under a pristine version of Xen. ........ 87 6.2 Identification under Reduced Runtime. The table reports the identification ac- curacy of Lycosid for a set of experiments in which a single hidden process must be identified among 10 active processes when the hidden process runs exponentially
Load more

Recommended publications
  • Intel X86 Considered Harmful
    Intel x86 considered harmful Joanna Rutkowska October 2015 Intel x86 considered harmful Version: 1.0 1 Contents 1 Introduction5 Trusted, Trustworthy, Secure?......................6 2 The BIOS and boot security8 BIOS as the root of trust. For everything................8 Bad SMM vs. Tails...........................9 How can the BIOS become malicious?.................9 Write-Protecting the flash chip..................... 10 Measuring the firmware: TPM and Static Root of Trust........ 11 A forgotten element: an immutable CRTM............... 12 Intel Boot Guard............................. 13 Problems maintaining long chains of trust............... 14 UEFI Secure Boot?........................... 15 Intel TXT to the rescue!......................... 15 The broken promise of Intel TXT.................... 16 Rescuing TXT: SMM sandboxing with STM.............. 18 The broken promise of an STM?.................... 19 Intel SGX: a next generation TXT?................... 20 Summary of x86 boot (in)security.................... 21 2 Intel x86 considered harmful Contents 3 The peripherals 23 Networking devices & subsystem as attack vectors........... 23 Networking devices as leaking apparatus................ 24 Sandboxing the networking devices................... 24 Keeping networking devices outside of the TCB............ 25 Preventing networking from leaking out data.............. 25 The USB as an attack vector...................... 26 The graphics subsystem......................... 29 The disk controller and storage subsystem............... 30 The audio
    [Show full text]
  • Accelerated AC Contingency Calculation on Commodity Multi
    1 Accelerated AC Contingency Calculation on Commodity Multi-core SIMD CPUs Tao Cui, Student Member, IEEE, Rui Yang, Student Member, IEEE, Gabriela Hug, Member, IEEE, Franz Franchetti, Member, IEEE Abstract—Multi-core CPUs with multiple levels of parallelism In the computing industry, the performance capability of (i.e. data level, instruction level and task/core level) have become the computing platform has been growing rapidly in the last the mainstream CPUs for commodity computing systems. Based several decades at a roughly exponential rate [3]. The recent on the multi-core CPUs, in this paper we developed a high performance computing framework for AC contingency calcula- mainstream commodity CPUs enable us to build inexpensive tion (ACCC) to fully utilize the computing power of commodity computing systems with similar computational power as the systems for online and real time applications. Using Woodbury supercomputers just ten years ago. However, these advances in matrix identity based compensation method, we transform and hardware performance result from the increasing complexity pack multiple contingency cases of different outages into a of the computer architecture and they actually increase the dif- fine grained vectorized data parallel programming model. We implement the data parallel programming model using SIMD ficulty of fully utilizing the available computational power for instruction extension on x86 CPUs, therefore, fully taking advan- a specific application [4]. This paper focuses on fully utilizing tages of the CPU core with SIMD floating point capability. We the computing power of modern CPUs by code optimization also implement a thread pool scheduler for ACCC on multi-core and parallelization for specific hardware, enabling the real- CPUs which automatically balances the computing loads across time complete ACCC application for practical power grids on CPU cores to fully utilize the multi-core capability.
    [Show full text]
  • On the Implementation of a Cloud-Based Computing Test Bench Environment for Prolog Systems †
    information Article On the Implementation of a Cloud-Based Computing Test Bench Environment for Prolog Systems † Ricardo Gonçalves, Miguel Areias * ID and Ricardo Rocha ID CRACS & INESC TEC and Faculty of Sciences, University of Porto, Rua do Campo Alegre, 1021/1055, 4169-007 Porto, Portugal; [email protected] (R.G.); [email protected] (R.R.) * Correspondence: [email protected] † This paper is an extended version of our paper published in the Symposium on Languages, Applications and Technologies 2017. Received: 13 September 2017; Accepted: 13 October 2017; Published: 19 October 2017 Abstract: Software testing and benchmarking are key components of the software development process. Nowadays, a good practice in large software projects is the continuous integration (CI) software development technique. The key idea of CI is to let developers integrate their work as they produce it, instead of performing the integration at the end of each software module. In this paper, we extend a previous work on a benchmark suite for the YAP Prolog system, and we propose a fully automated test bench environment for Prolog systems, named Yet Another Prolog Test Bench Environment (YAPTBE), aimed to assist developers in the development and CI of Prolog systems. YAPTBE is based on a cloud computing architecture and relies on the Jenkins framework as well as a new Jenkins plugin to manage the underlying infrastructure. We present the key design and implementation aspects of YAPTBE and show its most important features, such as its graphical user interface (GUI) and the automated process that builds and runs Prolog systems and benchmarks.
    [Show full text]
  • Attacking Intel® Trusted Execution Technology
    Attacking Intel® Trusted Execution Technology Rafal Wojtczuk Joanna Rutkowska [email protected] [email protected] ---===[ Invisible Things Lab ]===--- Abstract In this paper we present the results of our research into security of the Intel® Trusted Execution Technology, part of the vProTM brand. We describe a practical attack that is capable of bypassing the TXT's trusted boot process, a key building block for Intel's vision of Trusted Computing. As part of the attack we also discuss practical attacks on SMM memory in modern Intel systems. keywords: Trusted Computing, Trusted Execution Technology, System Management Mode, TXT, SMM, STM, BIOS, security, analysis, attacks. 1. Introduction and storing them in particular TPM registers. What is extraordinary here is that TXT doesn't make any Trusted Computing is becoming a part of our lives, assumptions about the state of the system before whether we want it or not. These days almost every loading the software, thus making it possible for a new laptop comes with an on-board Trusted user to ensure secure load of an OS or VMM, even Platform Module (TPM). Some of the Microsoft's in a potentially compromised machine. Palladium technologies made their way into Vista, and Microsoft BitLocker is, without doubt, the most In other words, our system can be full of boot successful, widely deployed product that is based sector viruses and BIOS rootkits, and god-knows- on the idea of Trusted Computing[8]. what-else, and still TXT should allow to load a clean VMM (or OS kernel) in a secure way, immune On the hardware side, besides the famed TPM, we to all those malware present in the system.
    [Show full text]
  • Specialising Dynamic Techniques for Implementing the Ruby Programming Language
    SPECIALISING DYNAMIC TECHNIQUES FOR IMPLEMENTING THE RUBY PROGRAMMING LANGUAGE A thesis submitted to the University of Manchester for the degree of Doctor of Philosophy in the Faculty of Engineering and Physical Sciences 2015 By Chris Seaton School of Computer Science This published copy of the thesis contains a couple of minor typographical corrections from the version deposited in the University of Manchester Library. [email protected] chrisseaton.com/phd 2 Contents List of Listings7 List of Tables9 List of Figures 11 Abstract 15 Declaration 17 Copyright 19 Acknowledgements 21 1 Introduction 23 1.1 Dynamic Programming Languages.................. 23 1.2 Idiomatic Ruby............................ 25 1.3 Research Questions.......................... 27 1.4 Implementation Work......................... 27 1.5 Contributions............................. 28 1.6 Publications.............................. 29 1.7 Thesis Structure............................ 31 2 Characteristics of Dynamic Languages 35 2.1 Ruby.................................. 35 2.2 Ruby on Rails............................. 36 2.3 Case Study: Idiomatic Ruby..................... 37 2.4 Summary............................... 49 3 3 Implementation of Dynamic Languages 51 3.1 Foundational Techniques....................... 51 3.2 Applied Techniques.......................... 59 3.3 Implementations of Ruby....................... 65 3.4 Parallelism and Concurrency..................... 72 3.5 Summary............................... 73 4 Evaluation Methodology 75 4.1 Evaluation Philosophy
    [Show full text]
  • Thesis May Never Have Been Completed
    UvA-DARE (Digital Academic Repository) Digital Equipment Corporation (DEC): A case study of indecision, innovation and company failure Goodwin, D.T. Publication date 2016 Document Version Final published version Link to publication Citation for published version (APA): Goodwin, D. T. (2016). Digital Equipment Corporation (DEC): A case study of indecision, innovation and company failure. General rights It is not permitted to download or to forward/distribute the text or part of it without the consent of the author(s) and/or copyright holder(s), other than for strictly personal, individual use, unless the work is under an open content license (like Creative Commons). Disclaimer/Complaints regulations If you believe that digital publication of certain material infringes any of your rights or (privacy) interests, please let the Library know, stating your reasons. In case of a legitimate complaint, the Library will make the material inaccessible and/or remove it from the website. Please Ask the Library: https://uba.uva.nl/en/contact, or a letter to: Library of the University of Amsterdam, Secretariat, Singel 425, 1012 WP Amsterdam, The Netherlands. You will be contacted as soon as possible. UvA-DARE is a service provided by the library of the University of Amsterdam (https://dare.uva.nl) Download date:26 Sep 2021 Digital Equipment Corporation (DEC) (DEC) Corporation Digital Equipment David Thomas David Goodwin Digital Equipment Corporation (DEC): A Case Study of Indecision, Innovation and Company Failure David Thomas Goodwin Digital Equipment Corporation (DEC): A Case Study of Indecision, Innovation and Company Failure David Thomas Goodwin 1 Digital Equipment Corporation (DEC): A Case Study of Indecision, Innovation and Company Failure ACADEMISCH PROEFSCHRIFT ter verkrijging van de graad van doctor aan de Universiteit van Amsterdam op gezag van de Rector Magnificus prof.
    [Show full text]
  • Yacc: Yet Another Compiler-Compiler
    Yacc: Yet Another Compiler-Compiler http://dinosaur.compilertools.net/yacc/index.html The Lex & Yacc Page Yacc: Yet Another Compiler-Compiler Stephen C. Johnson AT&T Bell Laboratories Murray Hill, New Jersey 07974 ABSTRACT Computer program input generally has some structure; in fact, every computer program that does input can be thought of as defining an ``input language'' which it accepts. An input language may be as complex as a programming language, or as simple as a sequence of numbers. Unfortunately, usual input facilities are limited, difficult to use, and often are lax about checking their inputs for validity. Yacc provides a general tool for describing the input to a computer program. The Yacc user specifies the structures of his input, together with code to be invoked as each such structure is recognized. Yacc turns such a specification into a subroutine that handles the input process; frequently, it is convenient and appropriate to have most of the flow of control in the user's application handled by this subroutine. The input subroutine produced by Yacc calls a user-supplied routine to return the next basic input item. Thus, the user can specify his input in terms of individual input characters, or in terms of higher level constructs such as names and numbers. The user-supplied routine may also handle idiomatic features such as comment and continuation conventions, which typically defy easy grammatical specification. Yacc is written in portable C. The class of specifications accepted is a very general one: LALR(1) grammars with disambiguating rules. In addition to compilers for C, APL, Pascal, RATFOR, etc., Yacc has also been used for less conventional languages, including a phototypesetter language, several desk calculator languages, a document retrieval system, and a Fortran debugging system.
    [Show full text]
  • End-To-End Verification of Memory Isolation
    Secure System Virtualization: End-to-End Verification of Memory Isolation HAMED NEMATI Doctoral Thesis Stockholm, Sweden 2017 TRITA-CSC-A-2017:18 KTH Royal Institute of Technology ISSN 1653-5723 School of Computer Science and Communication ISRN-KTH/CSC/A--17/18-SE SE-100 44 Stockholm ISBN 978-91-7729-478-8 SWEDEN Akademisk avhandling som med tillstånd av Kungl Tekniska högskolan framlägges till offentlig granskning för avläggande av teknologie doktorsexamen i datalogi fre- dagen den 20 oktober 2017 klockan 14.00 i Kollegiesalen, Kungl Tekniska högskolan, Brinellvägen 8, Stockholm. © Hamed Nemati, October 2017 Tryck: Universitetsservice US AB iii Abstract Over the last years, security kernels have played a promising role in re- shaping the landscape of platform security on today’s ubiquitous embedded devices. Security kernels, such as separation kernels, enable constructing high-assurance mixed-criticality execution platforms. They reduce the soft- ware portion of the system’s trusted computing base to a thin layer, which enforces isolation between low- and high-criticality components. The reduced trusted computing base minimizes the system attack surface and facilitates the use of formal methods to ensure functional correctness and security of the kernel. In this thesis, we explore various aspects of building a provably secure separation kernel using virtualization technology. In particular, we examine techniques related to the appropriate management of the memory subsystem. Once these techniques were implemented and functionally verified, they pro- vide reliable a foundation for application scenarios that require strong guar- antees of isolation and facilitate formal reasoning about the system’s overall security. We show how the memory management subsystem can be virtualized to enforce isolation of system components.
    [Show full text]
  • On the Cutting Edge: Thwarting Virtual Machine Detection
    On the Cutting Edge: Thwarting Virtual Machine Detection Tom Liston, Senior Security Consultant – Intelguardians Handler – SANS Internet Storm Center [email protected] Ed Skoudis, Founder / Senior Security Consultant – Intelguardians Handler – SANS Internet Storm Center [email protected] http://www.intelguardians.com ©2006 Tom Liston / Ed Skoudis 1 Hello, and welcome to our SANS@Night presentation on virtual machine detection, and some possible methods for thwarting the types of detection currently in use by malware in the wild. We’ll start things off with an overview of some of the methods being used to detect the use of virtual machine environments – how they work and what exactly they are detecting. Finally, we’ll pass along some tips for making use of a virtualized environment more difficult for the bad guys to detect. So, please sit back, relax, and follow along. If you have any questions, please feel free to ask! Tom Liston [email protected] Ed Skoudis [email protected] 1 Virtual Machine Environment A Apps Apps Apps p p l i c Guest Guest Guest a t i OS OS OS o n Virtualization Layer s (Process running on Host Operating System) Host Operating System Host computer x86 Architecture ©2006 Tom Liston / Ed Skoudis 2 Virtual machine environments (VMEs), such as VMware, VirtualPC, Xen, BOCHS, and User-Mode Linux, let a user or administrator run one or more “guest” operating systems on top of another “host” operating system. Each of the guest operating systems “run” in an emulated environment and are provided by the VME with mediated access to both virtual and real hardware.
    [Show full text]
  • Blue Pill – Creating Undetectable Malware on X64 Using Pacifica Technology
    Subverting VistaTM Kernel For Fun And Profit Joanna Rutkowska Advanced Malware Labs SyScan’06 July 21st, 2006, Singapore & Black Hat Briefings 2006 August 3rd, 2006, Las Vegas About this presentation This presentation is based on the research done exclusively for COSEINC Research This presentation has been first presented at SyScan conference in Singapore, on July 21st, 2006 © COSEINC Research, Advanced Malware Labs, 2006 2 Content Part I loading unsigned code into Vista Beta 2 kernel (x64) without reboot Part II Blue Pill – creating undetectable malware on x64 using Pacifica technology © COSEINC Research, Advanced Malware Labs, 2006 3 Part I – getting into the kernel Signed Drivers in Vista x64 All kernel mode drivers must be signed Vista allows to load only signed code into kernel Even administrator can not load unsigned module! This is to prevent kernel malware and anti-DRM Mechanism can be deactivated by: attaching Kernel Debugger (reboot required) Using F8 during boot (reboot required) using BCDEdit (reboot required, will not be available in later Vista versions) This protection has been for the first time implemented in Vista Beta 2 build 5384. © COSEINC Research, Advanced Malware Labs, 2006 5 How to bypass? Vista allows usermode app to get raw access to disk CreateFile(\\.\C:) CreateFile(\\.\PHYSICALDRIVE0)) This allows us to read and write disk sectors which are occupied by the pagefile So, we can modify the contents of the pagefile, which may contain the code and data of the paged kernel drivers! No undocumented functionality required – all documented in SDK :) © COSEINC Research, Advanced Malware Labs, 2006 6 Challenges How to make sure that the specific kernel code is paged out to the pagefile? How to find that code inside pagefile? How to cause the code (now modified) to be loaded into kernel again? How to make sure this new code is executed by kernel? © COSEINC Research, Advanced Malware Labs, 2006 7 How to force drivers to be paged? Allocate *lots of* memory for a process (e.g.
    [Show full text]
  • Sicstus Prolog User's Manual
    SICStus Prolog User's Manual Mats Carlsson et al. SICS Swedish ICT AB PO Box 1263 SE-164 29 Kista, Sweden Release 4.3.2 May 2015 SICS Swedish ICT AB [email protected] http://sicstus.sics.se/ Copyright c 1995-2015 SICS SICS Swedish ICT AB PO Box 1263 SE-164 29 Kista, Sweden Permission is granted to make and distribute verbatim copies of this manual provided the copyright notice and this permission notice are preserved on all copies. Permission is granted to copy and distribute modified versions of this manual under the con- ditions for verbatim copying, provided that the entire resulting derived work is distributed under the terms of a permission notice identical to this one. Permission is granted to copy and distribute translations of this manual into another lan- guage, under the above conditions for modified versions, except that this permission notice may be stated in a translation approved by SICS. i Table of Contents Introduction :::::::::::::::::::::::::::::::::::::::: 1 Acknowledgments :::::::::::::::::::::::::::::::::: 3 1 Notational Conventions :::::::::::::::::::::::: 5 1.1 Keyboard Characters::::::::::::::::::::::::::::::::::::::::::: 5 1.2 Mode Spec ::::::::::::::::::::::::::::::::::::::::::::::::::::: 5 1.3 Development and Runtime Systems::::::::::::::::::::::::::::: 5 1.4 Function Prototypes:::::::::::::::::::::::::::::::::::::::::::: 5 1.5 ISO Compliance:::::::::::::::::::::::::::::::::::::::::::::::: 6 2 Glossary ::::::::::::::::::::::::::::::::::::::::: 7 3 How to Run Prolog ::::::::::::::::::::::::::: 21 3.1 Getting
    [Show full text]
  • Background, Taxonomy for Secure Enclaves and Intel SGX Architecture
    Full text available at: http://dx.doi.org/10.1561/1000000051 Secure Processors Part I: Background, Taxonomy for Secure Enclaves and Intel SGX Architecture Victor Costan, Ilia Lebedev and Srinivas Devadas [email protected], [email protected] and [email protected] Computer Science and Artificial Intelligence Laboratory Massachusetts Institute of Technology Boston — Delft Full text available at: http://dx.doi.org/10.1561/1000000051 Foundations and Trends R in Electronic Design Automation Published, sold and distributed by: now Publishers Inc. PO Box 1024 Hanover, MA 02339 United States Tel. +1-781-985-4510 www.nowpublishers.com [email protected] Outside North America: now Publishers Inc. PO Box 179 2600 AD Delft The Netherlands Tel. +31-6-51115274 The preferred citation for this publication is V. Costan, I. Lebedev, and S. Devadas. Secure Processors Part I: Background, Taxonomy for Secure Enclaves and Intel SGX Architecture. Foundations and Trends R in Electronic Design Automation, vol. 11, no. 1-2, pp. 1–248, 2017. R This Foundations and Trends issue was typeset in LATEX using a class file de- signed by Neal Parikh. Printed on acid-free paper. ISBN: 978-1-68083-300-3 c 2017 V. Costan, I. Lebedev, and S. Devadas All rights reserved. No part of this publication may be reproduced, stored in a retrieval system, or transmitted in any form or by any means, mechanical, photocopying, recording or otherwise, without prior written permission of the publishers. Photocopying. In the USA: This journal is registered at the Copyright Clearance Cen- ter, Inc., 222 Rosewood Drive, Danvers, MA 01923. Authorization to photocopy items for internal or personal use, or the internal or personal use of specific clients, is granted by now Publishers Inc for users registered with the Copyright Clearance Center (CCC).
    [Show full text]