DOCSLIB.ORG

An X86 Protected Mode Virtual Machine Monitor for the MIT Exokernel by Charles L

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
An X86 Protected Mode Virtual Machine Monitor for the MIT Exokernel by Charles L An x86 Protected Mode Virtual Machine Monitor for the MIT Exokernel by Charles L. Coffing Submitted to the Department of Electrical Engineering and Computer Science in partial fulfillment of the requirements for the degrees of Bachelor of Science in Computer Science and Engineering and Master of Engineering in Computer Science at the MASSACHUSETTS INSTITUTE OF TECHNOLOGY May 1999 © Charles L. Coffing, NICMXCIX. A rights reserved. The author hereby grants to MIT permission to reproduce and distribute publicly paper and electronic copies of this thesis and to grant others the right to do so. MASSACHUSETTS NE OF TECHN 0 Author .............................. ... ......... Department of Electrical Engineering Computer Science A/- May 21, 1999 Certified by ............. ...................Fsh M. Frans Kaashoek Associate otessor z hes " ervisor Accepted by....... ........... Arthur C. Smith Chairman, Department Committee on Graduate Students An x86 Protected Mode Virtual Machine Monitor for the MIT Exokernel by Charles L. Coffing Submitted to the Department of Electrical Engineering and Computer Science on May 21, 1999, in partial fulfillment of the requirements for the degrees of Bachelor of Science in Computer Science and Engineering and Master of Engineering in Computer Science Abstract This thesis presents the design and implementation of an x86 virtual machine mon- itor that allows multiple operating systems to run concurrently under xok, MIT's x86-based exokernel. The monitor and modified xok demonstrate how to share sev- eral processor-defined structures, such as the GDT, LDT, and IDT, between multiple operating systems. Xok was modified to allow controlled modifications to these struc- tures. Linux was used as the reference guest operating system. The guest operating system is part of the trusted code base, but the monitor itself is not. Xok, the moni- tor, and the guest operating system coexist on the same pagetable to minimize TLB flushes. Real-mode virtualizations of disk and video devices were done. The resulting monitor was benchmarked against several other solutions, and thoughts for future improvements are presented. Thesis Supervisor: M. Frans Kaashoek Title: Associate Professor 2 Contents 1 Introduction 10 1.1 Background ..... ..... ..... ..... ..... ..... 10 1.2 Terminology ... .... .... .... .... ..... .... .... 11 1.3 Design strategy .. .... .... .... .... .... ..... ... 12 1.4 Thesis organization .. ..... ..... ..... ..... ..... 13 2 Related Work 14 2.1 Full emulation ... .... .... .... .... .... ..... ... 14 2.2 Binary emulation ... ..... ..... ..... ..... ..... 15 2.3 Virtual machine monitor .... ..... ..... ..... ..... 15 3 x86 Background 18 3.1 History .... ..... ..... ..... ..... ..... ..... 18 3.2 Operating modes ..... ..... ..... ...... ..... ... 19 3.3 Segmentation . ...... ...... ..... ...... ...... 20 3.4 Paging .. .... .... .... .... .... ..... .... .... 21 3.5 Privilege levels ... ..... ..... ..... ..... ..... .. 22 3.6 Registers ..... ...... ...... ....... ...... .... 22 3.7 Task management ..... ..... ..... ..... ..... .... 23 3.8 Interrupts and exceptions ..... ...... ...... ....... 23 4 Problems Virtualizing the x86 25 4.1 Privilege levels and segmentation ..... ...... ...... ... 25 3 4.2 Segment descriptor cache ... .... 26 4.3 Paging ..... ..... ...... 27 4.4 Untrappable instructions .. ..... 28 4.5 Summary of virtualization challenges 28 5 Design 30 5.1 Assumptions ............ .. 30 5.2 Solution overview ........... 31 5.3 Solution . .......... ..... 32 5.3.1 Emulation model ....... 32 5.3.2 Handler placement ...... 33 5.3.3 Segmentation ......... 33 5.3.4 Privilege levels ........ 34 5.4 Multiple guest operating systems 35 6 Memory Management 36 6.1 Requirements . ............ 36 6.1.1 Efficiency ........... ... .. .. ... .. .. 37 6.1.2 Speed ........... .. ... .. .. ... .. .. 3 7 6.1.3 Correctness ........ .. ... .. .. ... .. .. 3 8 6.2 D esign .......... ....... .. ... .. .. ... .. 3 9 6.2.1 Setup ........... .. ... .. .. ... .. .. 3 9 6.2.2 Page table management . .. ... .. .. ... .. .. 4 0 6.2.3 Changing page tables . .... .. ... ... .... ... 4 2 6.2.4 Page faults .. ........ .. ... .. .. ... .. 4 3 6.2.5 Tracking protected structures ... .. .. ... .. ... 4 3 6.2.6 Virtual address collisions . .. ..... ..... .... 4 4 6.3 Imperfect virtualization ... .... ... ... .. ... .. 4 8 6.3.1 Monitor location ... .... .. .. ... .. .. ... 4 8 6.3.2 Four megabyte pages . .... .. ... ... ... .. .. 4 9 6.3.3 Guests ......... .... .. ... .... ... ... 4 9 4 7 Segments 50 7.1 Xok segmentation .... ......... .... 50 7.2 Descriptor tables ............ ..... 51 7.2.1 GDT ... ............... .. 51 7.2.2 LD T .................... ........ ... 53 7.2.3 Trapping descriptor table modifications . ........ 55 7.2.4 Segment descriptor cache .. ....... 56 7.3 Imperfect virtualization .............. ... ........ 58 7.3.1 Descriptor tables ............. .. .... .... .. 58 7.3.2 Privilege levels and segmentation . ... ... ... .. ... 59 7.3.3 Segment descriptor cache ....... .. .... .... ... 6 1 8 Interrupts and Exceptions 63 8.1 Xok interrupt descriptor table ........ .. .. ... ... .. 63 8.2 Potential solutions to share the IDT ....... .... .... ... 64 8.2.1 Switching the IDT .......... .. .... .... ... 65 8.2.2 Multiplexing the IDT ........... .... .... ... 66 8.3 Multiplexing the IDT ............... ... ... .. ... 66 8.3.1 Catching guest exceptions and interrupts . .... .... ... 67 8.3.2 Handling exceptions in the monitor . .. .... .... ... 7 1 8.3.3 Emulating interrupt, task, and trap gates . .... .... ... 72 8.3.4 Returning to the guest .......... ... ... .. ... 73 8.3.5 Summary ................. .. .... .... .. 74 8.4 PIC virtualization .. ............... .. .. ... ... .. 75 8.5 Imperfect virtualization .............. .. .. .. .. .. 75 9 Device Virtualization 76 9.1 BIOS .... .... ... 76 9.2 Keyboard ... ..... 77 9.3 Video .......... 77 9.4 Disk .......... 78 5 10 Monitor Implementation 80 10.1 Exception handling .. 80 10.2 Compilation ...... 82 10.3 Configuration ..... 83 10.4 Debugger ....... 83 10.5 Usage . ........ 84 10.6 Status ...... ... 84 11 Xok 86 11.1 Helpful xok features .. ...... ..... 86 11.1.1 User defined trap handlers . .. .. 86 11.1.2 Batch system calls .. .. .. .... 86 11.2 Security of the modified xok . .. ..... 87 12 Performance 88 12.1 Benchmarking methodology 88 12.2 Benchmarks ....... .... 90 12.2.1 Computation: gzip . .. 90 12.2.2 Page table insertions: m iltiple pte 90 12.2.3 Page table insertions: sin gle pte 90 12.2.4 Comprehensive: boot .. 91 12.3 Results and Analysis ..... 91 12.3.1 Monitor invocation costs 94 13 Conclusion 97 13.1 Future work ...... ....... .... 97 13.1.1 Memory ..... .......... 97 13.1.2 Supported guest operating systems 99 13.1.3 Virtualized devices ..... .... 99 13.1.4 Hardware interrupts ........ 99 13.2 Conclusions ......... ........ 100 6 A Tables 101 B Figures 103 7 List of Figures 6-1 Virtual memory footprint of Linux overlaid on xok ...... ..... 47 B-1 Interrupt and exception handling from guest application using user- defined handlers. ..... ............ ........... 104 B-2 Interrupt and exception handling from guest application. ....... 105 B-3 Interrupt and exception handling from guest operating system. .... 106 B-4 Minimum cost of trapping from a guest operating system, emulating an instruction with xok system calls, and returning. .......... 107 8 List of Tables 2.1 Speed comparison of some emulation techniques ..... .. 15 5.1 Solution overview ....... ...... ....... .... 32 8.1 Xok interrupt descriptor table ....... ......... ..... 64 8.2 Gaining control of a guest interrupt or exception .. ..... 67 9.1 Data tables in the virtualized BIOS ......... ..... 77 10.1 Basic debugger commands .. ...... ....... .... 84 12.1 Speed comparison of four environments, in millions of cycles 92 12.2 Cost breakdown of monitor invocation, in cycles .. ..... 95 A.1 Summary of new xok system calls .... ....... .... 102 9 Chapter 1 Introduction 1.1 Background The paradigm of running exactly one operating system per personal computer is being threatened. The idea of running more than one operating system simultaneously is attracting interest, academically and commercially, because there now exists not only the power to do so but also the need. As Gordon Moore noted in a 1965 speech, the transistor counts and processing power of chips tend to double every 18 months. This trend, now known as Moore's Law, has held up well for thirty years and likely will continue in the foreseeable future. Additionally, in recent years the choice in PC operating systems has increased significantly beyond the mass-market standard of Windows. Multimedia-oriented operating systems are appearing and growing in importance, such as BeOS, which was first released on x86 in 1997. Linux, an open- source UNIX clone for personal computers, was first written in 1991 but had an explosion of popularity in 1998, with shipments growing 212% for the year in the server market, according to a study by International Data Corporation. In addition, numerous research operating systems are being or have been developed for the x86, each with their own advantages. There are numerous reasons for wanting to run multiple operating systems on a single PC. The most obvious reason is an economical one. As PCs become more powerful, an increasing number of uses do not fully tax the processor. Instead of 10 having a separate machine for each task, a new PC should be able to handle all tasks. Having the ability to simultaneously
Load more

Recommended publications
  • Allgemeines Abkürzungsverzeichnis
    Allgemeines Abkürzungsverzeichnis L.
    [Show full text]
  • VM Virtualization Tasks Problems of X86 Categories of X86 Virtualization
    VM Starts from IBM VM/370 definition: "an efficient, isolated duplicate of a real machine" Old purpose: share the resource of the expensive mainframe machine New purpose: fault tolerance and security; run multiple different OSes on the same desktop; server consolidation and performance isolation, etc. type 1 vmm: vmm running on bare hardware type 2 vmm: vmm running on host os Virtualization tasks (isolate, secure, fast, transparent …) 1. cpu virtualization How to make sure privileged instructions (e.g., enable/disable interrupts; change critical registers) will not be executed directly 2. memory virtualization OS thought they can control the whole physical memory. No! 3. I/O virtualization OS thought I/O devices are all under its own control. No! Problems of X86 1. Some privileged instructions do not trap; they just fail/change-semantic silently. 2. TLB miss will be handled by hardware instead of software Categories of X86 virtualization Full-virtualization (VMWare) No change to guest OS Use binary translation to change some instructions (privilege instructions or all OS code) on the fly Para-virtualization (Xen) Change guest OS to improve performance Rewrite OS; replace privileged instructions with hypercalls Many other changes Disco On MIPS DISCO directly runs on multi-processor machine; Oses run upon DISCO Goal: use commodity OSes to leverage many-core cluster VMM runs in kernel mode VM OS runs in supervisor mode VM user runs in user mode Privileged instructions will trap to VMM and be emulated CPU virtualization No special challenge (seemed that all privilege instructions will trap) VMM maintains a process-table-entry-like data structure for each VM (virtual PC) (including registers, states, and TLB content (used for emulation …) ).
    [Show full text]
  • Tricore™ Tricore™ V1.6 Microcontrollers User Manual
    TriCore™ 32-bit TriCore™ V1.6 Core Architecture 32-bit Unified Processor Core User Manual (Volume 1) V1.0, 2012-05 Microcontrollers Edition 2012-05 Published by Infineon Technologies AG 81726 Munich, Germany © 2012 Infineon Technologies AG All Rights Reserved. Legal Disclaimer The information given in this document shall in no event be regarded as a guarantee of conditions or characteristics. With respect to any examples or hints given herein, any typical values stated herein and/or any information regarding the application of the device, Infineon Technologies hereby disclaims any and all warranties and liabilities of any kind, including without limitation, warranties of non-infringement of intellectual property rights of any third party. Information For further information on technology, delivery terms and conditions and prices, please contact the nearest Infineon Technologies Office (www.infineon.com). Warnings Due to technical requirements, components may contain dangerous substances. For information on the types in question, please contact the nearest Infineon Technologies Office. Infineon Technologies components may be used in life-support devices or systems only with the express written approval of Infineon Technologies, if a failure of such components can reasonably be expected to cause the failure of that life-support device or system or to affect the safety or effectiveness of that device or system. Life support devices or systems are intended to be implanted in the human body or to support and/or maintain and sustain and/or protect human life. If they fail, it is reasonable to assume that the health of the user or other persons may be endangered.
    [Show full text]
  • PRE LIM INARY KDII-D Processor Manual (PDP-Ll/04)
    PRE LIM I N A R Y KDII-D Processor Manual (PDP-ll/04) The information in this document is subject to change without notice and should not be construed as a commitment by Digital Equipment Corporation. Digital Equipment Corporation assumes no responsibility for any errors that may appear in this manual. Copyright C 1975 by Digital Equipment Corporation Written by PDP-II Engineering PREFACE OVE~ALt DESCRIPTION 3 8 0 INsT~UCTION SET 3~1 Introduction 1~2 Addressing ModIs 3.3 Instruction Timing l@4 In~truet1on Dtlcriptlonl le!5 Dlffer~ncei a,tween KOlle and KOllS ]0 6 Programming Diftereneel B~twlen pepita ).7 SUI L~tency Tim@1 CPu OPERlTING 5PECIFICATID~S 5 e 0 DETAILED HARDWARE DESC~ltTION 5.1 IntrOduction 5 m2 Data path Circuitry 5.2g1 General D~serlpt1on 5.2,,2 ALU 5,2 .. 3 Scratch Pad Mtmory 5.2,.3.1 Scratch P~d Circuitry 5.2.3.2 SCrateh P~d Addr~11 MUltlplex.r 5.2.3.3 SCrateh Pad Regilter 5 0 2 .. 4 B J:H'!qilil ter 5.2 .. 4.1 B ReQister CircuItry 5.2 .. 4.2 8 L~G MUltl~lex@r 5,2.5 AMUX 5.2.6 Pfoeellof statuI Word (PSW) 5.3 Con<Htion COd@i 5.3.1 G~neral De~erl~tlon 5.3.2 Carry and overflow Decode 5.3.3 Ayte Multiplexing 5.4 UNIBUS Addf@$5 and Data Interfaces S.4 g 1 U~IBUS Dr1v~rl and ~lee1Vtrl 5.4@2 Bus Addr~s~ Generation 5 8 4111 Internal Addrf$$ D@coder 5 0 4,.4 Bus Data Line Interface S.5 Instruet10n DeCoding 5.5,,1 General De~er1pt1nn 5;5.2 Instruction Re91lt~r 5.5,,3 Instruetlon Decoder 5.5.3 0 1 Doubl~ O~erand InltrYetions 5.5.3.2 Single Operand Inltruetlons 5,5.3.3 Branch In$truetionl 5 8 5.3 6 4 Op~rate rn~truet1ons 5.6 Auil11ary ALU Control 5.6.1 G~ntral Delcrlptlon 5.6.2 COntrol Circuitry 5.6.2.1 Double Op@rand Instructions 5.6.2.2 Singl@ nDef~nd Instruet10ns PaQe 3 5.7 Data Transfer Control 5,7,1 General Descr1ption 5,7,2 Control CIrcuItry 5,7,2,1 Procelsor Cloek Inhibit 5,7,2.2 UNIBUS Synchronization 5,7.2,3 BUs Control 5.7,2.4 MSyN/SSYN Timeout 5,7.2.5 Bus Error.
    [Show full text]
  • LECTURE NOTE 5: the MEMORY MANAGEMENT REAL MODE Allows the Microprocessor to Address Only the First 1Mbyte of Memory Even If Its Pentium II Microprocessor
    LECTURE NOTE 5: THE MEMORY MANAGEMENT REAL MODE Allows the microprocessor to address only the first 1Mbyte of memory even if its Pentium II microprocessor. The first 1Mbyte of memory is called either the real mode or conventional memory system. The DOS operating system requires the microprocessor to operate in this mode. It allows application software. Segment and Offset Through the combination of these two, a memory location is accessed in the real mode. All real mode memory address must consist of a segment address plus an offset address. Segment Address Defines the beginning address of any 64k-byte memory segment. Offset Address Sometimes called displacement or relative. Selects any location within the 64k-byte memory segment. It is the distance above the start of the segment. Note: Each segment register is internally appended with a 0H on its right end. The segment address can begin only at a 16-byte boundary, which is called paragraph. Once the beginning address in known, an ending address is known, by adding FFFFH. The code segment register defines the start of the code segment and the instruction pointer to locate the next instruction within the code segment. This combination (CS:IP or CS:EIP) locates the next instruction executed by the microprocessor. Stack data are referenced through the stack segment at the memory location addressed by either the stack pointer (SP/ESP) or the base pointer (BP/EBP). These combinations are referred to as SS:SP (SS:ESP) or SS:BP (SS:EBP). Addressing Modes 1. Register Addressing Mode transfer a copy of a byte or word from the source register or memory location to the destination register or memory location.
    [Show full text]
  • Security Analysis of Encrypted Virtual Machines
    Security Analysis of Encrypted Virtual Machines Felicitas Hetzelt Robert Buhren Technical University of Berlin Technical University of Berlin Berlin, Germany Berlin, Germany fi[email protected] [email protected] Abstract 1. Introduction Cloud computing has become indispensable in today’s com- Cloud computing has been one of the most prevalent trends puter landscape. The flexibility it offers for customers as in the computer industry in the last decade. It offers clear ad- well as for providers has become a crucial factor for large vantages for both customers and providers. Customers can parts of the computer industry. Virtualization is the key tech- easily deploy multiple servers and dynamically allocate re- nology that allows for sharing of hardware resources among sources according to their immediate needs. Providers can different customers. The controlling software component, ver-commit their hardware and thus increase the overall uti- called hypervisor, provides a virtualized view of the com- lization of their systems. The key technology that made this puter resources and ensures separation of different guest vir- possible is virtualization, it allows multiple operating sys- tual machines. However, this important cornerstone of cloud tems to share hardware resources. The hypervisor is respon- computing is not necessarily trustworthy or bug-free. To mit- sible for providing temporal and spatial separation of the igate this threat AMD introduced Secure Encrypted Virtu- virtual machines (VMs). However, besides these advantages alization, short SEV, which transparently encrypts a virtual virtualization also introduced new risks. machines memory. Customers who want to utilize the infrastructure of a In this paper we analyse to what extend the proposed fea- cloud provider must fully trust the cloud provider.
    [Show full text]
  • What Is an Operating System III 2.1 Compnents II an Operating System
    Page 1 of 6 What is an Operating System III 2.1 Compnents II An operating system (OS) is software that manages computer hardware and software resources and provides common services for computer programs. The operating system is an essential component of the system software in a computer system. Application programs usually require an operating system to function. Memory management Among other things, a multiprogramming operating system kernel must be responsible for managing all system memory which is currently in use by programs. This ensures that a program does not interfere with memory already in use by another program. Since programs time share, each program must have independent access to memory. Cooperative memory management, used by many early operating systems, assumes that all programs make voluntary use of the kernel's memory manager, and do not exceed their allocated memory. This system of memory management is almost never seen any more, since programs often contain bugs which can cause them to exceed their allocated memory. If a program fails, it may cause memory used by one or more other programs to be affected or overwritten. Malicious programs or viruses may purposefully alter another program's memory, or may affect the operation of the operating system itself. With cooperative memory management, it takes only one misbehaved program to crash the system. Memory protection enables the kernel to limit a process' access to the computer's memory. Various methods of memory protection exist, including memory segmentation and paging. All methods require some level of hardware support (such as the 80286 MMU), which doesn't exist in all computers.
    [Show full text]
  • The Pentium Processor
    Chapter 7 The Pentium Processor 7–1 The main purpose of registers is to provide a scratch pad so that the processor can keep data on a temporary basis. For example, the processor may keep the procedure return address, stack pointer, instruction pointer, and so on. Registers are also used to keep the data handy so that it can avoid costly memory accesses. Keeping frequently accessed data in registers is a common compiler optimization technique. 7–2 Pentium supports the following three address spaces: 1. Linear address space 2. Physical address space 3. I/O address space (from discussion in Section 1.7) 7–3 In segmented memory organization, memory is partitioned into segments, where each segment is a small part of the memory. In the real mode, each segment of memory is a linear contiguous sequence of up to 64 KB. In the protected mode, it can be up to 4 GB. Pentium supports segmentation largely to provide backward compatibility to 8086. Note that 8086 is a 16-bit processor with 20 address lines. This mismatch between the processor’s 16-bit registers and 20-bit addresses is solved by using the segmented memory architecture. This segmented architecture has been carried over to Pentium. However, in the protected mode, it is possible to consider the entire memory as a single segment; thus, segmentation is completely turned off. 7–4 In the real mode, a segment is limited to 64 KB due to the fact that 16 bits are used to indicate the offset value into a segment. This magic number 16 is due to the 16-bit registers used 8086 processor.
    [Show full text]
  • Hardware Virtualization
    Hardware Virtualization E-516 Cloud Computing 1 / 33 Virtualization Virtualization is a vital technique employed throughout the OS Given a physical resource, expose a virtual resource through layering and enforced modularity Users of the virtual resource (usually) cannot tell the difference Different forms: Multiplexing: Expose many virtual resources Aggregation: Combine many physical resources [RAID, Memory] Emulation: Provide a different virtual resource 2 / 33 Virtualization in Operating Systems Virtualizing CPU enables us to run multiple concurrent processes Mechanism: Time-division multiplexing and context switching Provides multiplexing and isolation Similarly, virtualizing memory provides each process the illusion/abstraction of a large, contiguous, and isolated “virtual” memory Virtualizing a resource enables safe multiplexing 3 / 33 Virtual Machines: Virtualizing the hardware Software abstraction Behaves like hardware Encapsulates all OS and application state Virtualization layer (aka Hypervisor) Extra level of indirection Decouples hardware and the OS Enforces isolation Multiplexes physical hardware across VMs 4 / 33 Hardware Virtualization History 1967: IBM System 360/ VM/370 fully virtualizable 1980s–1990s: “Forgotten”. x86 had no support 1999: VMWare. First x86 virtualization. 2003: Xen. Paravirtualization for Linux. Used by Amazon EC2 2006: Intel and AMD develop CPU extensions 2007: Linux Kernel Virtual Machines (KVM). Used by Google Cloud (and others). 5 / 33 Guest Operating Systems VMs run their own operating system (called “guest OS”) Full Virtualization: run unmodified guest OS. But, operating systems assume they have full control of actual hardware. With virtualization, they only have control over “virtual” hardware. Para Virtualization: Run virtualization-aware guest OS that participates and helps in the virtualization. Full machine hardware virtualization is challenging What happens when an instruction is executed? Memory accesses? Control I/O devices? Handle interrupts? File read/write? 6 / 33 Full Virtualization Requirements Isolation.
    [Show full text]
  • Debugging a Program
    Debugging a Program SunPro A Sun Microsystems, Inc. Business 2550 Garcia Avenue Mountain View, CA 94043 U.S.A. Part No: 801-5106-10 Revision A December 1993 1993 Sun Microsystems, Inc. 2550 Garcia Avenue, Mountain View, California 94043-1100 U.S.A. All rights reserved. This product and related documentation are protected by copyright and distributed under licenses restricting its use, copying, distribution, and decompilation. No part of this product or related documentation may be reproduced in any form by any means without prior written authorization of Sun and its licensors, if any. Portions of this product may be derived from the UNIX® and Berkeley 4.3 BSD systems, licensed from UNIX System Laboratories, Inc. and the University of California, respectively. Third-party font software in this product is protected by copyright and licensed from Sun’s Font Suppliers. RESTRICTED RIGHTS LEGEND: Use, duplication, or disclosure by the United States Government is subject to the restrictions set forth in DFARS 252.227-7013 (c)(1)(ii) and FAR 52.227-19. The product described in this manual may be protected by one or more U.S. patents, foreign patents, or pending applications. TRADEMARKS Sun, Sun Microsystems, the Sun logo, SunPro, SunPro logo, Sun-4, SunOS, Solaris, ONC, OpenWindows, ToolTalk, AnswerBook, and Magnify Help are trademarks or registered trademarks of Sun Microsystems, Inc. UNIX and OPEN LOOK are registered trademarks of UNIX System Laboratories, Inc., a wholly owned subsidiary of Novell, Inc. All other product names mentioned herein are the trademarks of their respective owners. All SPARC trademarks, including the SCD Compliant Logo, are trademarks or registered trademarks of SPARC International, Inc.
    [Show full text]
  • Irmx® 286/Irmx® II Troubleshooting Guide
    iRMX® 286/iRMX® II Troubleshooting Guide Q1/1990 Order Number: 273472-001 inter iRMX® 286/iRMX® II Troubleshooting Guide Q1/1990 Order Number: 273472-001 Intel Corporation 2402 W. Beardsley Road Phoenix, Arizona Mailstop DV2-42 Intel Corporation (UK) Ltd. Pipers Way Swindon, Wiltshire SN3 1 RJ United Kingdom Intel Japan KK 5-6 Tokodai, Toyosato-machi Tsukuba-gun Ibaragi-Pref. 300-26 An Intel Technical Report from Technical Support Operations Copyright ©1990, Intel Corporation Copyright ©1990, Intel Corporation The information in this document is subject to change without notice. Intel Corporation makes no warranty of any kind with regard to this material, including, but not limited to, the implied warranties of merchantability and fitness for a particular purpose. Intel Corporation assumes no responsibility for any errors that ~ay :!ppe3r in this d~ur:::ent. Intel Corpomtion make:; nc ccmmitmcut tv update nor to keep C"l..iiTeilt thc information contained in this document. Intel Corporation assUmes no responsibility for the use of any circuitry other than circuitry embodied in an Intel product. No other circuit patent licenses are implied. Intel software products are copyrighted by and shall remain the property of Intel Corporation. Use, duplication or disclosure is subject to restrictions stated in Intel's software license, or as defined in FAR 52.227-7013. No part of this document may be copied or reproduced in any form or by any means without the prior written consent of Intel Corporation. The following are trademarks of Intel Corporation
    [Show full text]
  • Understanding the Microsoft Office 2013 Protected-View Sandbox
    MWRI PUBLIC UNDERSTANDING THE MICROSOFT OFFICE 2013 PROTECTED-VIEW SANDBOX Yong Chuan, Koh (@yongchuank) 2015/07/09 mwrinfosecurity.com | © MWR InfoSecurity MWRI PUBLIC MWRI PUBLIC Table of Contents 1. Introduction .................................................................................................................... 3 2. Sandbox Internals ............................................................................................................. 4 2.1 Architecture .............................................................................................................. 4 2.1.1 Interception Component ......................................................................................... 4 2.1.2 Elevation Policy Manager ........................................................................................ 4 2.1.3 Inter-Process Communication ................................................................................... 5 2.2 Sandbox Restrictions.................................................................................................... 6 2.2.1 Sandbox Initialization ............................................................................................ 6 2.2.2 File Locations .................................................................................................... 12 2.2.3 Registry Keys ..................................................................................................... 12 2.2.4 Network Connections ..........................................................................................
    [Show full text]