A Universal Framework for BIOS/UEFI Rootkits in System Management Mode

Total Page:16

File Type:pdf, Size:1020Kb

A Universal Framework for BIOS/UEFI Rootkits in System Management Mode LONGKIT – A Universal Framework for BIOS/UEFI Rootkits in System Management Mode Julian Rauchberger1, Robert Luh2 and Sebastian Schrittwieser2 1St. Poelten University of Applied Sciences, St. Poelten, Austria 2Josef Ressel Center TARGET, St. Poelten University of Applied Sciences, St. Poelten, Austria fi[email protected] Keywords: Malware, Rootkit, BIOS, UEFI, System Management Mode. Abstract: The theoretical threat of malware inside the BIOS or UEFI of a computer has been known for almost a decade. It has been demonstrated multiple times that exploiting the System Management Mode (SMM), an operating mode implemented in the x86 architecture and executed with high privileges, is an extremely powerful method for implanting persistent malware on computer systems. However, previous BIOS/UEFI malware concepts described in the literature often focused on proof-of-concept implementations and did not have the goal of demonstrating the full range of threats stemming from SMM malware. In this paper, we present LONGKIT, a novel framework for BIOS/UEFI malware in the SMM. LONGKIT is universal in nature, meaning it is fully written in position-independent assembly and thus also runs on other BIOS/UEFI implementations with min- imal modifications. The framework fully supports the 64-bit Intel architecture and is memory-layout aware, enabling targeted interaction with the operating system’s kernel. With LONGKIT we are able to demonstrate the full potential of malicious code in the SMM and provide researchers of novel SMM malware detection strategies with an easily adaptable rootkit to help evaluate their methods. 1 INTRODUCTION of a system are still underrepresented in security re- search and contain vulnerabilities that might prove Hiding malware such as rootkits or bootkits inside more tempting a target in the long term. the BIOS/UEFI of a computer has long been deemed The System Management Mode (SMM) is a a theoretical threat rather than an actual attack sur- legacy mode of operation available in x86 and x86-64 face. Implementation seemed too difficult and the CPUs. Originally, SMM was intended to be used for benefits for malicious actors aiming for quick profits maintenance tasks such as power and thermal man- were considered negligible. However, with the recent agement (Duflot et al., 2010). It is a highly privi- rise of Advanced Persistent Threats (APTs) and state- leged mode of operation which has free I/O access, sponsored attacks, sophisticated targeted attacks are can directly interact with memory and has no hard- now considered a realistic threat to businesses (Luh ware memory protections enabled. The operating sys- et al., 2016). For skilled attackers requiring high tem itself is suspended during SMM and is therefore stealth and persistence rather than widespread infec- unable to enforce any security policies. To emphasize tion, the BIOS/UEFI of a computer provides an ideal that SMM is even more privileged than hypervisors, target as it allows their payload to act independently it is often referred to as Ring -2 (Domas, 2015; Wo- of the operating system while still maintaining full jtczuk and Rutkowska, 2009). control over it. Moreover, in recent years, an in- Due to its high privileges, the SMM is one of the creased focus on security in software development key areas of many low-level attacks described in the can be observed and common attack surfaces such literature (Duflot et al., 2010; Kallenberg and Kovah, as operating systems and web browsers have become 2015; Domas, 2015; Duflot et al., 2006; Embleton more and more difficult to exploit. Today, a lot more and Sparks, 2008; Embleton et al., 2013; Schiffman investment is needed to compromise a system and and Kaplan, 2014). On modern operating systems, it ”low-hanging fruits” are slowly disappearing, which provides a level of access even above the kernel. The will force attackers to find different targets (Forristal, main motivation for SMM attacks is therefore the es- 2011). Lower operational levels such as the firmware calation of privileges, often with the goal of installing 346 Rauchberger, J., Luh, R. and Schrittwieser, S. LONGKIT – A Universal Framework for BIOS/UEFI Rootkits in System Management Mode. DOI: 10.5220/0006165603460353 In Proceedings of the 3rd International Conference on Information Systems Security and Privacy (ICISSP 2017), pages 346-353 ISBN: 978-989-758-209-7 Copyright c 2017 by SCITEPRESS – Science and Technology Publications, Lda. All rights reserved LONGKIT – A Universal Framework for BIOS/UEFI Rootkits in System Management Mode persistent malware on the system which is indepen- A recurring question regarding SMM malware re- dent from the operating system. volves around the level of control the SMM has over Malware running in System Management Mode the system and what malicious actions it can exe- provides attackers with several more advantages cute (Kallenberg et al., 2014; Kallenberg and Ko- which traditional kernel or userland based malware vah, 2015). Since SMM has direct access to physical does not have due to access restrictions. It has RAM, malware running inside its boundaries can es- extremely high stealth and persistence capabilities: sentially do everything lower privileged malware can. under normal circumstances, System Management The only difference is that said functionality might be RAM (SMRAM) cannot be read or written to from more difficult to implement because there is no au- outside the SMM, not even with Ring 0 privi- tomatic translation between virtual and physical ad- leges (Kallenberg and Kovah, 2015). Thus, SMM dresses (Duflot et al., 2006) and it is not possible to malware, which does not alter the operating system, directly call APIs of the operating system. Attack- is very hard to detect, requiring manual dumping and ers might have to reimplement certain functionality reverse engineering of the System Management Inter- which is otherwise easily accessible. rupt (SMI) handler. By demonstrating the very real threat posed by novel solutions such as LONGKIT, we hope to shift Contributions. The main contributions of this pa- attention to the SMM attack surface and inspire fu- per are: ture research in this area. We introduce a flexible framework for • BIOS/UEFI rootkits in the SMM. 2.1 Related Work We show how SMM rootkits can access the en- • tire 64-bit address space of the virtual memory by In the past, the SMM was shown to be exploitable by entering the Long Mode. attackers to bypass certain security features (Duflot et al., 2010). The authors identified four fundamental We explain LONGKIT’s ability of interfering with flaws in the design of the SMM which they attribute to • the operating system’s kernel by locating and the fact that security has mostly been an afterthought parsing the page table used by the OS. in the specification. Moreover, they also identified We present a prototype of the LONGKIT frame- • two common design flaws in SMI handlers. These work as well as the implementation and evaluation are not flaws in the specification but rather commonly of two typical rootkit functionalities (login bypass made programming mistakes which subvert security. and system call hooking). Similar observations have been made by (Kallenberg and Kovah, 2015). Boot script vulnerabilities are a class of attacks 2 BACKGROUND that apply only to UEFI systems as they rely on in- terpretation of the S3 boot script data structure which SMM can only be entered when the CPU receives is a feature of UEFI firmware. S3 resume allows for a a System Management Interrupt (SMI) which is a faster startup during a suspend/resume cycle by skip- hardware interrupt. However, triggering an SMI in ping certain parts of a normal boot sequence and ex- software is also possible, for instance by writing ecuting the S3 boot script to restore configuration. If to the Advanced Power Management Control Reg- this script is stored insecurely, attackers with Ring 0 ister (APMC) (Duflot et al., 2010). Upon receiving privileges can modify it and execute arbitrary code an SMI, the CPU will enter SMM and execute the during early boot (Wojtczuk and Kallenberg, 2014). System Management Interrupt Handler which is lo- Additionally to the classes of attack vectors speci- cated in System Management RAM (SMRAM) (Du- fied above, other, less generic exploits have been pub- flot et al., 2010). SMRAM is a special region in mem- lished in the past. Speed Racer (Kallenberg and Wo- ory which, if correctly configured, can only be read jtczuk, 2015) is a race condition found on multi-core and written to when the CPU is in System Manage- systems with chipsets lacking or making no use of the ment Mode (Duflot et al., 2006). A part of SMRAM is SMM BWP (SMM BIOS Write Protect Disable) reg- reserved for the state save area where the contents of ister. When this register is set, the BIOS region is only most CPU registers are stored when entering SMM. writable if all processors are in SMM. If this feature When the SMI handler has finished, it executes the is missing or unused, a race condition exists which al- RSM assembly instruction which restores the registers lows reflashing of firmware by continuously attempt- with the values in the state save area and returns con- ing to unlock the BIOS region on one core and writing trol to the operating system. to it on another core. In some cases, the firmware can- 347 ICISSP 2017 - 3rd International Conference on Information Systems Security and Privacy not re-lock memory fast enough and the write will go only capability is to scan memory for a certain signa- through. Another attack, The Memory Sinkhole (Do- ture. If this signature is found, data following there- mas, 2015), abuses a legacy feature of modern pro- after will be executed as code by the rootkit (Kallen- cessors that allows remapping of the Advanced Pro- berg et al., 2014).
Recommended publications
  • SO630 Manual
    SO630 ATX Industrial Motherboard User’s Manual A-604-M-2045 ver.MP_MP_4-1521_15-14 Copyright FCC and DOC Statement on Class B This publication contains information that is protected by copyright. No part of it may be repro- This equipment has been tested and found to comply with the limits for a Class B digital duced in any form or by any means or used to make any transformation/adaptation without the device, pursuant to Part 15 of the FCC rules. These limits are designed to provide reason- prior written permission from the copyright holders. able protection against harmful interference when the equipment is operated in a residential installation. This equipment generates, uses and can radiate radio frequency energy and, if not installed and used in accordance with the instruction manual, may cause harmful interference This publication is provided for informational purposes only. The manufacturer makes no to radio communications. However, there is no guarantee that interference will not occur in a representations or warranties with respect to the contents or use of this manual and specifi- particular installation. If this equipment does cause harmful interference to radio or television cally disclaims any express or implied warranties of merchantability or fitness for any particular reception, which can be determined by turning the equipment off and on, the user is encour- purpose. The user will assume the entire risk of the use or the results of the use of this docu- aged to try to correct the interference by one or more of the following measures: ment. Further, the manufacturer reserves the right to revise this publication and make changes to its contents at any time, without obligation to notify any person or entity of such revisions or • Reorient or relocate the receiving antenna.
    [Show full text]
  • 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]
  • Status Update on PCI Express Support in Qemu
    Status Update on PCI Express Support in QEmu Isaku Yamahata, VA Linux Systems Japan K.K. <[email protected]> Xen Summit North America April 28, 2010 Agenda ● Introduction ● Usage and Example ● Implementation Details ● Future Work ● Considerations on further development issues Introduction From http://en.wikipedia.org/wiki/PCI_Express PCI Express native Hotplug Electro Mechanical Lock(EMI) Slot Number From http://docs.hp.com/ Eventual Goal Dom0 qemu-dm interrupt root DomU Inject the error up Virtual PCIe Bus down Interrupt to notify the error Xen VMM hardware PCI express bus PCI Express root port PCI Express upstream port PCI Express Error Message native passthrough PCI Express downstream port With native hot plug support Error PCI Express device Eventual Goal ● More PCI features/PCI express features – The current emulated chipset(I440FX/PIIX3) is too old. – So new Chipset emulator is wanted. ● Xen PCI Express support – PCI Express native hotplug – PCI Express native passthourgh ● When error is detected via AER(Advanced Error Reporting), inject the error into the guest. ● these require several steps, so the first step is... First Phase Goal ● Make Qemu PCI Express ready – Introduce new chipset emulator(Q35) ● PCI Express native hot plug ● Implement PCI Express port emulators, and make it possible to inject errors into guest Current status Qemu/PCI express ● PCIe MMCONFIG Merged. the qemu/guest Q35 chipset base working PCIe portemulator working PCIe native hotplug working firmware PCIe AER WIP PCIe error injection WIP VBE paravirtualization working enhancement is seabios mcfg working almost done. e820 working host bridge initiazatlin working ● pci io/memory The next step is space initialization working passing acpi table outside qemu working qemu upstream vgabios VBE paravirtualization working merge.
    [Show full text]
  • SYSCALL, IRET ● Opportunistic SYSRET Failed, Do IRET
    entry_*.S A carefree stroll through kernel entry code Borislav Petkov SUSE Labs [email protected] Reasons for entry into the kernel ● System calls (64-bit, compat, 32-bit) ● Interrupts (NMIs, APIC, timer, IPIs... ) – software: INT 0x0-0xFF, INT3, … – external (hw-generated): CPU-ext logic, async to insn exec ● Architectural exceptions (sync vs async) – faults: precise, reported before faulting insn => restartable (#GP,#PF) – traps: precise, reported after trapping insn (#BP,#DB-both) – aborts: imprecise, not reliably restartable (#MC, unless MCG_STATUS.RIPV) 2 Intr/Ex entry ● IDT, int num index into it (256 vectors); all modes need an IDT ● If handler has a higher CPL, switch stacks ● A picture is always better: 3 45sec guide to Segmentation ● Continuous range at an arbitrary position in VA space ● Segments described by segment descriptors ● … selected by segment selectors ● … by indexing into segment descriptor tables (GDT,LDT,IDT,...) ● … and loaded by the hw into segment registers: – user: CS,DS,{E,F,G}S,SS – system: GDTR,LDTR,IDTR,TR (TSS) 4 A couple more seconds of Segmentation ● L (bit 21) new long mode attr: 1=long mode, 0=compat mode ● D (bit 22): default operand and address sizes ● legacy: D=1b – 32bit, D=0b – 16bit ● long mode: D=0b – 32-bit, L=1,D=1 reserved for future use ● G (bit 23): granularity: G=1b: seg limit scaled by 4K ● DPL: Descriptor Privilege Level of the segment 5 Legacy syscalls ● Call OS through gate descriptor (call, intr, trap or task gate) ● Overhead due to segment-based protection: – load new selector + desc into
    [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]
  • CS3210: Booting and X86
    1 CS3210: Booting and x86 Taesoo Kim 2 What is an operating system? • e.g. OSX, Windows, Linux, FreeBSD, etc. • What does an OS do for you? • Abstract the hardware for convenience and portability • Multiplex the hardware among multiple applications • Isolate applications to contain bugs • Allow sharing among applications 3 Example: Intel i386 4 Example: IBM T42 5 Abstract model (Wikipedia) 6 Abstract model: CPU, Memory, and I/O • CPU: execute instruction, IP → next IP • Memory: read/write, address → data • I/O: talk to external world, memory-mapped I/O or port I/O I/O: input and output, IP: instruction pointer 7 Today: Bootstrapping • CPU → what's first instruction? • Memory → what's initial code/data? • I/O → whom to talk to? 8 What happens after power on? • High-level: Firmware → Bootloader → OS kernel • e.g., jos: BIOS → boot/* → kern/* • e.g., xv6: BIOS → bootblock → kernel • e.g., Linux: BIOS/UEFI → LILO/GRUB/syslinux → vmlinuz • Why three steps? • What are the handover protocols? 9 BIOS: Basic Input/Output System • QEMU uses an opensource BIOS, called SeaBIOS • e.g., try to run, qemu (with no arguments) 10 From power-on to BIOS in x86 (miniboot) • Set IP → 4GB - 16B (0xfffffff0) • e.g., 80286: 1MB - 16B (0xffff0) • e.g., SPARCS v8: 0x00 (reset vector) DEMO : x86 initial state on QEMU 11 The first instruction • To understand, we first need to understand: 1. x86 state (e.g., registers) 2. Memory referencing model (e.g,. segmentation) 3. BIOS features (e.g., memory aliasing) (gdb) x/1i 0xfffffff0 0xfffffff0: ljmp $0xf000,$0xe05b 12 x86
    [Show full text]
  • Contents of DOWNLOAD.ZIP Contents of This
    F2 motherboard BIOS update „WN DOS 21/01“ Contents of DOWNLOAD.ZIP *UPDATE????IMG.EXE Win-Image executable for Windows: Creates a bootable DOS based update disk on 1,44MB/3,5" floppy. *UPDATE????DD.BIN Image file for Linux (dd): Creates a bootable DOS based update disk on 1,44MB/3,5" floppy. \DOS\*.* Contains all update files for USB stick or other media README.PDF This information ???? .............................. Actual BIOS release number * …………………………. Motherboard type Contents of this README file CONTENTS OF DOWNLOAD.ZIP............................................................................. 1 CONTENTS OF THIS README FILE ....................................................................... 1 GENERAL REMARKS............................................................................................... 1 Known problems or restrictions .......................................................................................................... 1 LIMITS AND FEATURES OF F2 DOS BIOS ............................................................. 2 Default setup values.............................................................................................................................. 3 CRISIS DISK FOR BIOS RECOVERY....................................................................... 4 DOS BASED UPDATE PROCEDURE RELEASE 4.6............................................... 4 Running DOS BIOS update from external USB boot media.............................................................. 4 Running DOS BIOS update from CD-ROM.........................................................................................
    [Show full text]
  • X86 Memory Protection and Translation
    2/5/20 COMP 790: OS Implementation COMP 790: OS Implementation Logical Diagram Binary Memory x86 Memory Protection and Threads Formats Allocators Translation User System Calls Kernel Don Porter RCU File System Networking Sync Memory Device CPU Today’s Management Drivers Scheduler Lecture Hardware Interrupts Disk Net Consistency 1 Today’s Lecture: Focus on Hardware ABI 2 1 2 COMP 790: OS Implementation COMP 790: OS Implementation Lecture Goal Undergrad Review • Understand the hardware tools available on a • What is: modern x86 processor for manipulating and – Virtual memory? protecting memory – Segmentation? • Lab 2: You will program this hardware – Paging? • Apologies: Material can be a bit dry, but important – Plus, slides will be good reference • But, cool tech tricks: – How does thread-local storage (TLS) work? – An actual (and tough) Microsoft interview question 3 4 3 4 COMP 790: OS Implementation COMP 790: OS Implementation Memory Mapping Two System Goals 1) Provide an abstraction of contiguous, isolated virtual Process 1 Process 2 memory to a program Virtual Memory Virtual Memory 2) Prevent illegal operations // Program expects (*x) – Prevent access to other application or OS memory 0x1000 Only one physical 0x1000 address 0x1000!! // to always be at – Detect failures early (e.g., segfault on address 0) // address 0x1000 – More recently, prevent exploits that try to execute int *x = 0x1000; program data 0x1000 Physical Memory 5 6 5 6 1 2/5/20 COMP 790: OS Implementation COMP 790: OS Implementation Outline x86 Processor Modes • x86
    [Show full text]
  • Virtual Memory in X86
    Fall 2017 :: CSE 306 Virtual Memory in x86 Nima Honarmand Fall 2017 :: CSE 306 x86 Processor Modes • Real mode – walks and talks like a really old x86 chip • State at boot • 20-bit address space, direct physical memory access • 1 MB of usable memory • No paging • No user mode; processor has only one protection level • Protected mode – Standard 32-bit x86 mode • Combination of segmentation and paging • Privilege levels (separate user and kernel) • 32-bit virtual address • 32-bit physical address • 36-bit if Physical Address Extension (PAE) feature enabled Fall 2017 :: CSE 306 x86 Processor Modes • Long mode – 64-bit mode (aka amd64, x86_64, etc.) • Very similar to 32-bit mode (protected mode), but bigger address space • 48-bit virtual address space • 52-bit physical address space • Restricted segmentation use • Even more obscure modes we won’t discuss today xv6 uses protected mode w/o PAE (i.e., 32-bit virtual and physical addresses) Fall 2017 :: CSE 306 Virt. & Phys. Addr. Spaces in x86 Processor • Both RAM hand hardware devices (disk, Core NIC, etc.) connected to system bus • Mapped to different parts of the physical Virtual Addr address space by the BIOS MMU Data • You can talk to a device by performing Physical Addr read/write operations on its physical addresses Cache • Devices are free to interpret reads/writes in any way they want (driver knows) System Interconnect (Bus) : all addrs virtual DRAM Network … Disk (Memory) Card : all addrs physical Fall 2017 :: CSE 306 Virt-to-Phys Translation in x86 0xdeadbeef Segmentation 0x0eadbeef Paging 0x6eadbeef Virtual Address Linear Address Physical Address Protected/Long mode only • Segmentation cannot be disabled! • But can be made a no-op (a.k.a.
    [Show full text]
  • Protected Mode - Wikipedia
    2/12/2019 Protected mode - Wikipedia Protected mode In computing, protected mode, also called protected virtual address mode,[1] is an operational mode of x86- compatible central processing units (CPUs). It allows system software to use features such as virtual memory, paging and safe multi-tasking designed to increase an operating system's control over application software.[2][3] When a processor that supports x86 protected mode is powered on, it begins executing instructions in real mode, in order to maintain backward compatibility with earlier x86 processors.[4] Protected mode may only be entered after the system software sets up one descriptor table and enables the Protection Enable (PE) bit in the control register 0 (CR0).[5] Protected mode was first added to the x86 architecture in 1982,[6] with the release of Intel's 80286 (286) processor, and later extended with the release of the 80386 (386) in 1985.[7] Due to the enhancements added by protected mode, it has become widely adopted and has become the foundation for all subsequent enhancements to the x86 architecture,[8] although many of those enhancements, such as added instructions and new registers, also brought benefits to the real mode. Contents History The 286 The 386 386 additions to protected mode Entering and exiting protected mode Features Privilege levels Real mode application compatibility Virtual 8086 mode Segment addressing Protected mode 286 386 Structure of segment descriptor entry Paging Multitasking Operating systems See also References External links History https://en.wikipedia.org/wiki/Protected_mode
    [Show full text]
  • The Evolution of an X86 Virtual Machine Monitor
    The Evolution of an x86 Virtual Machine Monitor Ole Agesen, Alex Garthwaite, Jeffrey Sheldon, Pratap Subrahmanyam {agesen, alextg, jeffshel, pratap}@vmware.com ABSTRACT While trap-and-emulate virtualization on mainframes was Twelve years have passed since VMware engineers first virtu- well understood at the time, it was – unsurprisingly – not a alized the x86 architecture. This technological breakthrough design goal for the 4004, whose first application was in fact kicked off a transformation of an entire industry, and virtu- a Busicom calculator [7]. However, as x86 CPUs expanded alization is now (once again) a thriving business with a wide their reach, the case for virtualization gradually emerged. range of solutions being deployed, developed and proposed. There was just one problem, seemingly fundamental: the But at the base of it all, the fundamental quest is still the generally accepted wisdom held that x86 virtualization was same: running virtual machines as well as we possibly can impossible, or at best merely impractical, due to inherited on top of a virtual machine monitor. architectural quirks and a requirement to retain compatibil- ity with legacy code. We review how the x86 architecture was originally virtual- ized in the days of the Pentium II (1998), and follow the This impasse was broken twelve years ago when VMware evolution of the virtual machine monitor forward through engineers first virtualized the x86 architecture entirely in the introduction of virtual SMP, 64 bit (x64), and hard- software. By basing the virtual machine monitor (VMM) ware support for virtualization to finish with a contempo- on binary translation, the architectural features that pre- rary challenge, nested virtualization.
    [Show full text]
  • Kshot: Live Kernel Patching with SMM and SGX
    KShot: Live Kernel Patching with SMM and SGX Lei Zhou∗y, Fengwei Zhang∗, Jinghui Liaoz, Zhengyu Ning∗, Jidong Xiaox Kevin Leach{, Westley Weimer{ and Guojun Wangk ∗Department of Computer Science and Engineering, Southern University of Science and Technology, Shenzhen, China, zhoul2019,zhangfw,ningzy2019 @sustech.edu.cn f g ySchool of Computer Science and Engineering, Central South University, Changsha, China zDepartment of Computer Science, Wayne State University, Detroit, USA, [email protected] xDepartment of Computer Science, Boise State University, Boise, USA, [email protected] Department of Computer Science and Engineering, University of Michigan, Ann Arbor, USA, kjleach,weimerw @umich.edu { f g kSchool of Computer Science and Cyber Engineering, Guangzhou University, Guangzhou, China, [email protected] Abstract—Live kernel patching is an increasingly common kernel vulnerabilities also merit patching. Organizations often trend in operating system distributions, enabling dynamic up- use rolling upgrades [3], [6], in which patches are designed dates to include new features or to fix vulnerabilities without to affect small subsystems that minimize unplanned whole- having to reboot the system. Patching the kernel at runtime lowers downtime and reduces the loss of useful state from running system downtime, to update and patch whole server systems. applications. However, existing kernel live patching techniques However, rolling upgrades do not altogether obviate the need (1) rely on specific support from the target operating system, to restart software or reboot systems; instead, dynamic hot and (2) admit patch failures resulting from kernel faults. We patching (live patching) approaches [7]–[9] aim to apply present KSHOT, a kernel live patching mechanism based on patches to running software without having to restart it.
    [Show full text]