DOCSLIB.ORG

A Study of Using Hardware-Assisted Isolated Execution Environments for Security

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
A Study of Using Hardware-Assisted Isolated Execution Environments for Security SoK: A Study of Using Hardware-assisted Isolated Execution Environments for Security Fengwei Zhang Hongwei Zhang Department of Computer Science Department of Computer Science Wayne State University Wayne State University [email protected] [email protected] ABSTRACT are crucial to secure computer systems: The isolated exe- Hardware-assisted Isolated Execution Environments (HIEEs) cution concept provides a Trusted Execution Environment have been widely adopted to build effective and efficient de- (TEE) for running defensive tools on a compromised sys- fensive tools for securing systems. Hardware vendors have tem. Using hardware-assisted technologies excludes the hy- introduced a variety of HIEEs including system management pervisors from TCB, achieves a high level of privilege (i.e., mode, Intel management engine, ARM TrustZone, and Intel hardware-level privilege), and reduces performance overhead software guard extensions. This SoK paper presents a com- giving that context switches are performed faster in hard- prehensive study of existing HIEEs and compares their fea- ware. tures from the security perspective. Additionally, we explore In this SoK paper, we survey the state-of-the-art sys- both defensive and offensive use scenarios of HIEEs and dis- tems that leverage HIEEs for security. We first study six cuss the attacks against HIEE-based systems. Overall, this hardware-level computing environments (i.e., HIEEs) that paper aims to give an essential checkpoint of the state-of- have been used for building security tools. Based on the the-art systems that use HIEEs for trustworthy computing. timelines they introduced, we categorize them as follows. 1) Legacy HIEEs: System Management Mode (SMM) and Dy- namic Root of Trust for Measurements (DRTM); 2) recent Keywords HIEEs: Intel Management Engine (ME), AMD Platform Se- Isolated execution environments, hardware, security curity Processor (PSP), and ARM TrustZone; 3) the latest HIEE: Intel Software Guard Extensions (SGX). We discuss the security usage scenarios of HIEEs from both defensive 1. INTRODUCTION and offensive points of view, and further describe these us- Isolating code execution is one of the fundamental ap- age scenarios along with the existing HIEE-based systems. proaches to achieving security. Researchers use virtualiza- Additionally, we identify attacks and security concerns to tion technology to create an isolated execution environment HIEE-based systems from two aspects: 1) the isolated com- for running defensive tools. Moreover, Virtual machine in- puting environments (i.e., HIEEs themselves) and 2) the trospection [21] has been widely adopted for attacks detec- approach of using HIEEs for security. For each HIEE it- tion and malware analysis. However, existing virtualization- self, we enumerate potential attacks against it and describe based approaches have limitations including: 1) Dependence corresponding mitigations. In terms of the approach of us- on hypervisors that may have a large Trusted Computing ing HIEEs for security in general, we raise security con- Base (TCB). For instance, the latest Xen hypervisor has cerns such as ensuring trusted path and verifying trustwor- 532K lines of source code obtained from [11]. 2) Failure to thy hardware. Note that the concept of HIEE needs to be deal with hypervisor or firmware rootkits. Virtualization- distinguished from TEE. On one hand, a TEE may not be based approaches rely on hypervisors so they cannot analyze a HIEE such as software-based TEEs (e.g., virtualization the same or higher privilege-level rootkits. And 3) suffering technology); on the other hand, a HIEE does not have to be from system performance overhead (e.g., context switches a TEE (e.g., SMM is a HIEE but may not be a TEE because from a VM to a hypervisor). it is not designed for security). In light of these problems, researchers proposed to use The main contributions of this SoK paper are: Hardware-assisted Isolated Execution Environments (HIEEs) for securing systems. This approach combines the isolated • We present a thorough study of six HIEEs including execution concept with hardware-assisted technologies. Both SMM, Intel ME, AMD PSP, DRTM, Intel SGX, and ARM TrustZone, and compare their hardware features Permission to make digital or hard copies of all or part of this work for personal or for trustworthy computing. classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies bear this notice and the full cita- • We explore both the defensive and offensive use sce- tion on the first page. Copyrights for components of this work owned by others than ACM must be honored. Abstracting with credit is permitted. To copy otherwise, or re- narios of HIEEs and describe them with the state-of- publish, to post on servers or to redistribute to lists, requires prior specific permission the-art HIEE-based systems. and/or a fee. Request permissions from [email protected]. HASP 2016, June 18 2016, , • We discuss all attacks against the computing environ- c 2016 ACM. ISBN 978-1-4503-4769-3/16/06. $15.00 ment of each HIEE (e.g., bypassing the isolation) and DOI: http://dx.doi.org/10.1145/2948618.2948621 some mitigations. • We raise the concerns about the approach of using Protected Mode System Management Mode HIEEs for security including ensuring the trusted switch- ing path and verifying trustworthiness of hardware tech- Highest privilege nologies. Trigger SMI Software SMM entry SMI or Isolated SMRAM The rest of the paper is organized as follows. Section 2 SMM exit Handler Hardware explains different HIEEs including SMM, Intel ME, AMD RSM Interrupts disabled PSP, DRTM, Intel SGX, and ARM TrustZone. Section 3 presents the security use cases of HIEEs. Section 4 presents all attacks against the HIEEs. Section 5 discusses the secu- Normal OS Isolated Execution Environment rity concerns of the HIEE-based approach. Lastly, Section 6 concludes the SoK paper with our expectations. Figure 1: SMI Triggering Process 2. HIEE tablets, and smart phones [36]. Intel introduced ME as an In this section, we first explain Hardware-assisted Isolated embedded processor in 2007. At that time, its main func- Execution Environments (HIEEs) including system manage- tion was to support Intel Active Management Technology ment mode, Intel management engine, AMD secure proces- (AMT), and Intel AMT is the first application running in sor, dynamic root of trust for measurement, Intel software the ME. Recently, Intel started to use ME as a Trusted Exe- guard extension, and ARM TrustZone. Then, we briefly cution Environmental (TEE) for executing security-sensitive compare these HIEEs. applications. According to the latest ME book [36] written by an Intel Architect working on ME, a few security appli- 2.1 System Management Mode cations have been or will be implemented in ME including System Management Mode (SMM) [24] is a mode of ex- enhanced privacy identification, protected audio video path, ecution similar to Real and Protected modes available on identity protection technology, and boot guard. x86 platforms (Intel started to use SMM in its Pentium Figure 2 shows the hardware architecture of ME. From processors since early 90s). It provides a hardware-assisted the figure we can see that ME is like a computer; it contains isolated execution environment for implementing platform- a processor, cryptography engine, Direct Memory Access specific system control functions such as power management. (DMA) engine, Host-Embedded Communication Interface It is initialized by the Basic Input/Output System (BIOS). (HECI) engine, Read-Only Memory (ROM), internal Static SMM is triggered by asserting the System Management Random-Access Memory (SRAM), a timer, and other I/O Interrupt (SMI) pin on the CPU. This pin can be asserted devices. ME executes the instructions on the processor, and in a variety of ways, which include writing to a hardware it has code and data caches to reduce the number of ac- port or generating Message Signaled Interrupts with a PCI cesses to the internal SRAM. The internal SRAM is used to device. Next, the CPU saves its state to a special region store the firmware code and runtime data. Besides the in- of memory called System Management RAM (SMRAM). ternal SRAM, ME also uses some Dynamic Random-Access Then, it atomically executes the SMI handler stored in SM- Memory (DRAM) from the main system's memory (i.e., host RAM. SMRAM cannot be addressed by the other modes of memory). This DRAM serves a role as the disk; the mem- execution. The requests for addresses in SMRAM are in- ory pages of code/data that are not currently used by ME stead forwarded to video memory by default. This caveat processor will be evicted from SRAM and swapped out to therefore allows SMRAM to be used as a secure storage. The DRAM in the host memory. The region of DRAM is re- SMI handler is loaded into SMRAM by the BIOS at boot served by the BIOS when system boots. This DRAM is time. The SMI handler has unrestricted access to the phys- dedicated for ME use and the operating system cannot ac- ical address space and can run privileged instructions (For cess it. However, the design of ME does not trust the BIOS this reason, SMM is often referred to as ring -2.) The RSM and it assumes the host can access the reserved DRAM re- instruction forces the CPU to exit from SMM and resume gion. execution in the previous mode. Since the embedded processor (i.e., ME processor) cannot In general, there are software- and hardware-based meth- address the host memory, two engines (i.e., DAM engine ods to trigger an SMI. In software, we can write to an ACPI and HECI engine) are introduced for the data transmission port to raise an SMI. For example, Intel chipsets use port between the ME memory and the main system's memory.
Load more

Recommended publications
  • Intel's SL Enhanced Intel486(TM) Microprocessor Family
    Intel's SL Enhanced Intel486(TM) Microprocessor Family http://www.intel.com/design/intarch/applnots/7014.htm Intel's SL Enhanced Intel486(TM) Microprocessor Family Intel's SL Enhanced Intel486™ Microprocessor Family Technical Backgrounder June 1993 Intel's SL Enhanced Intel486™ Microprocessor Family With the announcement of the SL Enhanced Intel486™ microprocessor family, Intel Corporation brings energy efficiency to its entire line of Intel486™ microprocessors. SL Technology, originally developed for mobile PCs, now provides superior power-management features for desktop computer systems. Such energy-efficient systems will be designed to meet or exceed the Energy Star guidelines set by the Environmental Protection Agency. The EPA's Energy Star program is aimed at reducing power consumption of desktop computer systems, thereby reducing their impact on the environment. In addition, SL Enhanced Intel486™ microprocessors will enable a new class of notebook systems -- high-performance Intel486™ DX2 CPU-based notebooks with color displays that do not sacrifice battery life. The SL Enhanced Intel486™ microprocessor family is available in a complete range of price/performance, package and voltage options. This flexibility allows PC makers to develop products that meet the mobile and desktop needs of all their customers in the mobile and desktop markets, from low-cost, entry-level Intel486™ SX microprocessor-based systems to high-performance, high-end Intel486™ DX2 microprocessor-based systems. Since the SL Technology in SL Enhanced Intel486™ microprocessors is the same as in Intel SL CPUs, computer manufacturers with prior experience developing systems based on existing SL BIOS will be able to incorporate System Management Mode's (SMM) power-management features into new systems.
    [Show full text]
  • Iocheck: a Framework to Enhance the Security of I/O Devices at Runtime
    IOCheck: A Framework to Enhance the Security of I/O Devices at Runtime Fengwei Zhang Center for Secure Information Systems George Mason University Fairfax, VA 22030 [email protected] Abstract—Securing hardware is the foundation for implement- Management Mode (SMM), a CPU mode in the x86 archi- ing a secure system. However, securing hardware devices remains tecture, to quickly check the integrity of I/O configurations an open research problem. In this paper, we present IOCheck, and firmware. Unlike previous systems [11], [12], IOCheck a framework to enhance the security of I/O devices at runtime. enumerates all of the I/O devices on the motherboard, and It leverages System Management Mode (SMM) to quickly check checks the integrity of their corresponding configurations and the integrity of I/O configurations and firmware. IOCheck does not rely on the operating system and is OS-agnostic. In our firmware. IOCheck does not rely on the operating system, preliminary results, IOCheck takes 4 milliseconds to switch to which significantly reduces the Trust Computing Base (TCB). SMM which introduces low performance overhead. In addition, IOCheck is able to achieve better performance compared to TXT or SVM approaches. For example, the SMM Keywords—Integrity, Firmware, I/O Configurations, SMM switching time is much faster than the late launch method in Flicker [10], [13]. We will demonstrate that IOCheck is able to check the integrity of array of I/O devices including the BIOS, I. INTRODUCTION IOMMU, network card, video card, keyboard, and mouse. With the increasing complexity of hardware devices, Contributions. The purpose of this work is to make the firmware functionality is expanding, exposing new vulner- following contributions: abilities to attackers.
    [Show full text]
  • Embedded Intel486™ Processor Hardware Reference Manual
    Embedded Intel486™ Processor Hardware Reference Manual Release Date: July 1997 Order Number: 273025-001 The embedded Intel486™ processors may contain design defects known as errata which may cause the products to deviate from published specifications. Currently characterized errata are available on request. Information in this document is provided in connection with Intel products. No license, express or implied, by estoppel or oth- erwise, to any intellectual property rights is granted by this document. Except as provided in Intel’s Terms and Conditions of Sale for such products, Intel assumes no liability whatsoever, and Intel disclaims any express or implied warranty, relating to sale and/or use of Intel products including liability or warranties relating to fitness for a particular purpose, merchantability, or infringement of any patent, copyright or other intellectual property right. Intel products are not intended for use in medical, life saving, or life sustaining applications. Intel retains the right to make changes to specifications and product descriptions at any time, without notice. Contact your local Intel sales office or your distributor to obtain the latest specifications and before placing your product order. Copies of documents which have an ordering number and are referenced in this document, or other Intel literature, may be obtained from: Intel Corporation P.O. Box 7641 Mt. Prospect, IL 60056-7641 or call 1-800-879-4683 or visit Intel’s web site at http:\\www.intel.com Copyright © INTEL CORPORATION, July 1997 *Third-party brands and names are the property of their respective owners. CONTENTS CHAPTER 1 GUIDE TO THIS MANUAL 1.1 MANUAL CONTENTS ..................................................................................................
    [Show full text]
  • Sok: Hardware Security Support for Trustworthy Execution
    SoK: Hardware Security Support for Trustworthy Execution Lianying Zhao1, He Shuang2, Shengjie Xu2, Wei Huang2, Rongzhen Cui2, Pushkar Bettadpur2, and David Lie2 1Carleton Universityz, Ottawa, ON, Canada 2University of Toronto, Toronto, ON, Canada Abstract—In recent years, there have emerged many new hard- contribute to lowering power consumption, which is critical ware mechanisms for improving the security of our computer for resource-constrained devices. systems. Hardware offers many advantages over pure software Furthermore, hardware is the Root of Trust (RoT) [48], as approaches: immutability of mechanisms to software attacks, better execution and power efficiency and a smaller interface it bridges the physical world (where human users reside) and allowing it to better maintain secrets. This has given birth to the digital world (where tasks run as software). To securely a plethora of hardware mechanisms providing trusted execution perform a task or store a secret, the user trusts at least part of environments (TEEs), support for integrity checking and memory the computer hardware. safety and widespread uses of hardware roots of trust. Dedicated hardware security support has seen its prolif- In this paper, we systematize these approaches through the lens eration since the early days of computers. It can take a of abstraction. Abstraction is key to computing systems, and the interface between hardware and software contains many abstrac- straightforward form as discrete components to assist the tions. We find that these abstractions, when poorly designed, can CPU, ranging from the industrial-grade tamper-responding both obscure information that is needed for security enforcement, IBM Cryptocards (e.g., 4758 [37]), Apple’s proprietary secure as well as reveal information that needs to be kept secret, leading enclave processor (SEP [84]) for consumer electronics, to the to vulnerabilities.
    [Show full text]
  • SMM) Xeno Kovah && Corey Kallenberg Legbacore, LLC All Materials Are Licensed Under a Creative Commons “Share Alike” License
    Advanced x86: BIOS and System Management Mode Internals System Management Mode (SMM) Xeno Kovah && Corey Kallenberg LegbaCore, LLC All materials are licensed under a Creative Commons “Share Alike” license. http://creativecommons.org/licenses/by-sa/3.0/ ABribuEon condiEon: You must indicate that derivave work "Is derived from John BuBerworth & Xeno Kovah’s ’Advanced Intel x86: BIOS and SMM’ class posted at hBp://opensecuritytraining.info/IntroBIOS.html” 2 System Management Mode (SMM) God Mode AcEvate 3 Batteries Not Included! From http://support.amd.com/us/Processor_TechDocs/24593.pdf 4 System Management Mode (SMM) Overview • Most privileged x86 processor operating mode • Runs transparent to the operating system • When the processor enters SMM, all other running tasks are suspended • SMM can be invoked only by a System Management Interrupt (SMI) and exited only by the RSM (resume) instruction • Intended use is to provide an isolated operating environment for – Power/Battery management – Controlling system hardware – Running proprietary OEM code – etc. (anything that should run privileged and uninterrupted) 5 System Management Mode (SMM) Overview • The code that executes in SMM (called the SMI handler) is instantiated from the BIOS flash • Protecting SMM is a matter of protecting both the active (running) SMRAM address space but also protecting the flash chip from which it is derived – Protect itself (SMBASE (location), SMRAM Permissions) – Write-Protect Flash • So far in our research, only about 5% of SMRAM configurations were directly unlocked and vulnerable to overwrite • However, since > 50% of the BIOS flash chips we've seen are vulnerable, that means > 50% of SMRAM will follow suit 6 System Management Interrupt (SMI) • SMM can only be invoked by signaling a System Management Interrupt (SMI) • SMI’s can be received via the SMI# pin on the processor or through the APIC bus • SMI’s cannot be masked like normal interrupts (e.g.
    [Show full text]
  • Hardware-Assisted Rootkits: Abusing Performance Counters on the ARM and X86 Architectures
    Hardware-Assisted Rootkits: Abusing Performance Counters on the ARM and x86 Architectures Matt Spisak Endgame, Inc. [email protected] Abstract the OS. With KPP in place, attackers are often forced to move malicious code to less privileged user-mode, to ele- In this paper, a novel hardware-assisted rootkit is intro- vate privileges enabling a hypervisor or TrustZone based duced, which leverages the performance monitoring unit rootkit, or to become more creative in their approach to (PMU) of a CPU. By configuring hardware performance achieving a kernel mode rootkit. counters to count specific architectural events, this re- Early advances in rootkit design focused on low-level search effort proves it is possible to transparently trap hooks to system calls and interrupts within the kernel. system calls and other interrupts driven entirely by the With the introduction of hardware virtualization exten- PMU. This offers an attacker the opportunity to redirect sions, hypervisor based rootkits became a popular area control flow to malicious code without requiring modifi- of study allowing malicious code to run underneath a cations to a kernel image. guest operating system [4, 5]. Another class of OS ag- The approach is demonstrated as a kernel-mode nostic rootkits also emerged that run in System Manage- rootkit on both the ARM and Intel x86-64 architectures ment Mode (SMM) on x86 [6] or within ARM Trust- that is capable of intercepting system calls while evad- Zone [7]. The latter two categories, which leverage vir- ing current kernel patch protection implementations such tualization extensions, SMM on x86, and security exten- as PatchGuard.
    [Show full text]
  • 80486DX2-66-Intel-Datasheet-7086155.Pdf
    Distributed by: www.Jameco.com ✦ 1-800-831-4242 The content and copyrights of the attached material are the property of its owner. EMBEDDED IntelDX2™ PROCESSOR ■ Integrated Floating-Point Unit ■ SL Technology ■ Speed-Multiplying Technology ■ Data Bus Parity Generation and Checking ■ 32-Bit RISC Technology Core ■ Boundary Scan (JTAG) ■ 8-Kbyte Write-Through Cache ■ 3.3-Volt Processor, 50 MHz, 25 MHz CLK ■ Four Internal Write Buffers — 208-Lead Shrink Quad Flat Pack (SQFP) ■ ■ Burst Bus Cycles 5-Volt Processor, 66 MHz, 33 MHz CLK — 168-Pin Pin Grid Array (PGA) ■ Dynamic Bus Sizing for 8- and 16-bit Data Bus Devices ■ Binary Compatible with Large Software Base 64-Bit Interunit Transfer Bus 32-Bit Data Bus Core CLK Clock Clock 32-Bit Data Bus Multiplier Linear Address 32 PCD PWT Bus Interface Barrel Base/ Segmentation 2 A31-A2 Shifter Index Unit Paging Cache Unit 32 Address BE3#- BE0# Bus Unit 20 Drivers Register 32 Descriptor File Registers Physical 8 Kbyte Write Buffers Address 32 4 x 32 Translation Cache ALU Limit and D31-D0 Attribute PLA Lookaside Data Bus Buffer 32 Transceivers Bus Control ADS# W/R# D/C# M/IO# PCD PWT RDY# LOCK# 128 PLOCK# BOFF# A20M# Displacement Bus BREQ HOLD HLDA RESET SRESET INTR 32 NMI SMI# SMIACT# Prefetcher FERR# IGNNE# Micro- STPCLK# Instruction Request Sequencer 32-Byte Code BRDY# BLAST# Queue Burst Bus Code Control Stream 2x16 Bytes Floating Control & Instruction Bus Size BS16# BS8# 24 Point Unit Protection Decode Control Test Unit Cache KEN# FLUSH# Floating Decoded AHOLD EADS# Control Instruction Control Point Path Register File ROM Parity DP3-DP0 PCHK# Generation and Control Boundary TCK TMS TDI TD0 Scan Control A3223-01 Figure 1.
    [Show full text]
  • PERFORMANCE IMPLICATIONS of SYSTEM MANAGEMENT MODE Brian Delgado†, Karen L
    In Proceedings of the IEEE International Symposium on Workload Characterization (IISWC), Sept. 2013 (c) IEEE 2013 PERFORMANCE IMPLICATIONS OF SYSTEM MANAGEMENT MODE Brian Delgado†, Karen L. Karavanic Portland State University bdelgado, [email protected] ABSTRACT [4] dramatically change expectations over its use. Since System Management Mode (SMM) is a special x86 processor SMM completely pauses host software execution for the mode that privileged software such as kernels or hypervisors duration of its work and the time required for these new cannot access or interrupt. Previously, it has been assumed usages exceeds common SMI durations, there are clear that time spent in SMM would be relatively small and performance concerns. In recent years, applications have therefore its side effects on privileged software were moved from running on native operating systems where unimportant; recently, researchers have proposed uses, such they were impacted by other processes as well as the as security-related checks, that would greatly increase the operating system to running within virtualized amount of runtime spent in this mode. We present the environments which added virtualization-level impacts. results of a detailed performance study to characterize the SMM RIMMs would cause another source of impact on performance impacts of SMM, using measurement infrastructure we have developed. Our study includes applications as well as the virtualized environments on impact to application, system, and hypervisor. We show which they run. Applications running under hypervisors there can be clear negative effects from prolonged watched by an SMM RIMM would experience the preemptions. However, if SMM duration is kept within combined impacts of each layer.
    [Show full text]
  • Co-Processor-Based Behavior Monitoring
    Co-processor-based Behavior Monitoring: Application to the Detection of Attacks Against the System Management Mode Ronny Chevalier, Maugan Villatel, David Plaquin, Guillaume Hiet To cite this version: Ronny Chevalier, Maugan Villatel, David Plaquin, Guillaume Hiet. Co-processor-based Behavior Monitoring: Application to the Detection of Attacks Against the System Management Mode. ACSAC 2017 - 33rd Annual Computer Security Applications Conference, Dec 2017, Orlando, United States. pp.399-411, 10.1145/3134600.3134622. hal-01634566 HAL Id: hal-01634566 https://hal.inria.fr/hal-01634566 Submitted on 6 Dec 2017 HAL is a multi-disciplinary open access L’archive ouverte pluridisciplinaire HAL, est archive for the deposit and dissemination of sci- destinée au dépôt et à la diffusion de documents entific research documents, whether they are pub- scientifiques de niveau recherche, publiés ou non, lished or not. The documents may come from émanant des établissements d’enseignement et de teaching and research institutions in France or recherche français ou étrangers, des laboratoires abroad, or from public or private research centers. publics ou privés. Co-processor-based Behavior Monitoring: Application to the Detection of Attacks Against the System Management Mode Ronny Chevalier Maugan Villatel HP Labs HP Labs [email protected] [email protected] David Plaquin Guillaume Hiet HP Labs CentraleSupélec [email protected] [email protected] ABSTRACT 1 INTRODUCTION Highly privileged software, such as firmware, is an attractive target Computers often relies on low-level software, like the kernel of for attackers. Thus, BIOS vendors use cryptographic signatures to an Operating System (OS) or software embedded in the hardware, ensure firmware integrity at boot time.
    [Show full text]
  • Chapter 3 Basic Execution Environment
    CHAPTER 3 BASIC EXECUTION ENVIRONMENT This chapter describes the basic execution environment of an Intel 64 or IA-32 processor as seen by assembly- language programmers. It describes how the processor executes instructions and how it stores and manipulates data. The execution environment described here includes memory (the address space), general-purpose data registers, segment registers, the flag register, and the instruction pointer register. 3.1 MODES OF OPERATION The IA-32 architecture supports three basic operating modes: protected mode, real-address mode, and system management mode. The operating mode determines which instructions and architectural features are accessible: • Protected mode — This mode is the native state of the processor. Among the capabilities of protected mode is the ability to directly execute “real-address mode” 8086 software in a protected, multi-tasking environment. This feature is called virtual-8086 mode, although it is not actually a processor mode. Virtual-8086 mode is actually a protected mode attribute that can be enabled for any task. • Real-address mode — This mode implements the programming environment of the Intel 8086 processor with extensions (such as the ability to switch to protected or system management mode). The processor is placed in real-address mode following power-up or a reset. • System management mode (SMM) — This mode provides an operating system or executive with a transparent mechanism for implementing platform-specific functions such as power management and system security. The processor enters SMM when the external SMM interrupt pin (SMI#) is activated or an SMI is received from the advanced programmable interrupt controller (API C). In SMM, the processor switches to a separate address space while saving the basic context of the currently running program or task.
    [Show full text]
  • CIS 3207 - Operating Systems CPU Mode
    CIS 3207 - Operating Systems CPU Mode Professor Qiang Zeng Spring 2018 CPU Modes • Two common modes – Kernel mode • The CPU has to be in this mode to execute the kernel code – User mode • The CPU has to be in this mode to execute the user code CIS 3207 – Operating Systems 2 Important questions • How are CPU modes implemented? • Why are CPU modes needed? • Difference between Kernel mode and User mode • How are system calls implemented? • Advanced topic: Virtualization CIS 3207 – Operating Systems 3 How CPU Modes are implemented • Implemented through protection rings – A modern CPU typical provides different protection rings, which represent different privilege levels • A ring with a lower number has higher privileges – Introduced by Multics in 60’s – E.g., an X86 CPU usually provides four rings, and a Linux/Unix/Windows OS uses Ring 0 for the kernel mode and Ring 3 for the user mode CIS 3207 – Operating Systems 4 Why are Protection Rings needed? • Fault isolation: a fault (e.g., divided by 0) in the code running in a less-privileged ring can be captured and handled by code in a more-privileged ring • Privileged instructions: certain instructions can only be issued in a privileged ring; thus an OS can implement resource management and isolation here • Privileged memory space: certain memory can only be accessed in a privileged ring All these are demonstrated in the difference between the kernel mode and the user mode CIS 3207 – Operating Systems 5 Kernel Mode vs. User Mode? • A fault in the user space (e.g., divided by zero, invalid access,
    [Show full text]
  • (12) United States Patent (10) Patent No.: US 9.223,730 B2 Lin Et Al
    US00922373OB2 (12) United States Patent (10) Patent No.: US 9.223,730 B2 Lin et al. (45) Date of Patent: Dec. 29, 2015 (54) VIRTUAL SYSTEM MANAGEMENT MODE (56) References Cited DEVICE AND CONTROL METHOD THEREOF U.S. PATENT DOCUMENTS 6.799.316 B1* 9/2004 Aguilar et al. .................... T18, 1 (71) Applicant: WISTRON CORP., New Taipei (TW) 2010/0162242 A1* 6, 2010 Grouzdev ...... ... 718.1 2015,0040 130 A1 2/2015 Ali et al. ........................... T18, 1 (72) Inventors: Wen-Tai Lin, New Taipei (TW); Yuan-Chan Lee, New Taipei (TW) OTHER PUBLICATIONS (73) Assignee: Wistron Corp., New Taipei (TW) Taiwan Patent Office, Office Action, Patent Application No. 101109290, Apr. 11, 2014, Taiwan. (*) Notice: Subject to any disclaimer, the term of this All I Know about SCI, http://diablo0709.blogspot.tw/2013/04/aii-i- patent is extended or adjusted under 35 know-about-sci.html, Apr. 10, 2013, 6 pages, Taiwan. U.S.C. 154(b) by 570 days. KBSMI & KBSCI, http://boy-asmc.blogspot.tw/2011/03/eckbSmi. html, Mar. 25, 2011, 3 pages,Taiwan. (21) Appl. No.: 13/685,618 * cited by examiner (22) Filed: Nov. 26, 2012 Primary Examiner — Nimesh G Patel (65) Prior Publication Data (57) ABSTRACT US 2013/0246678A1 Sep. 19, 2013 A virtual system management mode device, for processing a (30) Foreign Application Priority Data system management interrupt signal generated by a special process, includes a transformation unit, a control unit Mar. 19, 2012 (TW) ............................. 10110929OA memory, and a control unit. The transformation unit trans forms the system management interrupt signal into a virtual (51) Int.
    [Show full text]