Analysis of x86 Application and System Programs via Machine-Code Verification Shilpi Goel, Warren A. Hunt, Jr., and Matt Kaufmann Department of Computer Science The University of Texas at Austin 1 University Way, M/S C0500 Austin, TX 78712-0233 [email protected] TEL: +1 512 471 9748 FAX: +1 512 471 8885 April, 2016 Introduction Motivation: Increase the reliability of programs used in the industry Approach: Machine-code verification for x86 platforms -We are developing a formal x86 model in ACL2 for code analysis. -We are vetting our tools on commercial-sized problems. Today, we talk about our ongoing work in formal verification of software, and present our plans to verify supervisor-level code in the immediate future. Objective: Emulate an operating system, like FreeBSD, along with the programs running on it, and prove properties about kernel code Introduction 2 /27 Ecosystem Our group has significant collaboration with the government and industry. Our own research includes: - Development of core technologies - Application of these technologies in different domains - Validation of commercial processor designs at Centaur and Oracle (10+ developers, 30+ users) Introduction 3 /27 Project Overview Goal: Build robust tools to increase software reliability ‣ Verify critical properties of application and system programs ‣ Correctness with respect to behavior, security, & resource usage Plan of Action: 1. Build a formal, executable x86 ISA model using 2. Develop a machine-code analysis framework based on this model 3. Employ this framework to verify application and system programs Introduction 4 /27 Contributions A new tool: General-purpose analysis framework for x86 machine-code ‣ Accurate x86 ISA reference Program verification taking memory management into account: ‣ Properties of x86 memory-management data structures ‣ Analysis of programs, including low-level system & ISA features Reasoning strategies: Insight into low-level code verification in general ‣ Build effective lemma libraries Foundation for future research: ‣ Target for verified/verifying compilers ‣ Resource usage guarantees ‣ Information-flow analysis ‣ Ensuring process isolation Introduction 5 /27 Outline ๏ Motivation ๏ Project Description ➡ [1] Developing an x86 ISA Model ➡ [2] Building a Machine-Code Analysis Framework ➡ [3] Verifying Application and System Programs ๏ Future Work & Conclusion ๏ Accessing Source Code + Documentation 6 /27 Model Development Obtaining the x86 ISA Specification Model Development 7 /27 Model Development Obtaining the x86 ISA Specification ~3400 pages Model Development 7 /27 Model Development Obtaining the x86 ISA Specification All AMD manuals: ~3000 pages ~3400 pages Model Development 7 /27 Model Development Obtaining the x86 ISA Specification __asm__ volatile ("stc\n\t" // Set CF. "mov $0, %%eax\n\t" // Set EAX = 0. "mov $0, %%ebx\n\t" // Set EBX = 0. "mov $0, %%ecx\n\t" // Set ECX = 0. "mov %4, %%ecx\n\t" // Set CL = rotate_by. "mov %3, %%edx\n\t" // Set EDX = old_cf = 1. All AMD manuals: ~3000 pages ~3400 "mov pages %2, %%eax\n\t" // Set EAX = num. "rcl %%cl, %%al\n\t" // Rotate AL by CL. "cmovb %%edx, %%ebx\n\t" // Set EBX = old_cf if CF = 1. // Otherwise, EBX = 0. "mov %%eax, %0\n\t" // Set res = EAX. "mov %%ebx, %1\n\t" // Set cf = EBX. : "=g"(res), "=g"(cf) : "g"(num), "g"(old_cf), "g"(rotate_by) : "rax", "rbx", "rcx", "rdx"); Model Development Running tests on x86 machines 7 /27 Model Development Focus: 64-bit sub-mode of Intel’s IA-32e mode Model Development 8 /27 BASIC EXECUTION ENVIRONMENT • Debug registers —Model Debug registers expand Development to 64 bits. See Chapter 17, “Debug, Branch Profile, TSC, and Quality of Service,” in the Intel® 64 and IA-32 Architectures Software Developer’s Manual, Volume 3A. • Descriptor table registers — The global descriptor table register (GDTR) and interrupt descriptor table register (IDTR) expand to 10 bytes so that they can hold a full 64-bit base address. The local descriptor table Focus:register (LDTR) 64-bitand the task register sub-mode (TR) also expand to of hold aIntel’s full 64-bit base IA-32eaddress. mode Basic Program Execution Registers Address Space 2^64 -1 Sixteen 64-bit General-Purpose Registers Registers Six 16-bit Segment Registers Registers 64-bits RFLAGS Register 64-bits RIP (Instruction Pointer Register) FPU Registers Eight 80-bit Floating-Point Registers Data Registers 0 16 bits Control Register 16 bits Status Register 16 bits Tag Register Opcode Register (11-bits) 64 bits FPU Instruction Pointer Register 64 bits FPU Data (Operand) Pointer Register MMX Registers Eight 64-bit MMX Registers Registers XMM Registers Sixteen 128-bit Registers XMM Registers 32-bits MXCSR Register Figure 3-2. 64-Bit Mode Execution Environment Model Development 8 /27 Source: Intel Manuals 3.3 MEMORY ORGANIZATION The memory that the processor addresses on its bus is called physical memory. Physical memory is organized as a sequence of 8-bit bytes. Each byte is assigned a unique address, called a physical address. The physical address space ranges from zero to a maximum of 236 − 1 (64 GBytes) if the processor does not support Intel Vol. 1 3-5 BASIC EXECUTION ENVIRONMENT • Debug registers —Model Debug registers expand Development to 64 bits. See Chapter 17, “Debug, Branch Profile, TSC, and Quality of Service,” in the Intel® 64 and IA-32 Architectures Software Developer’s Manual, Volume 3A. SYSTEM ARCHITECTURE OVERVIEW • Descriptor table registers — The global descriptor table register (GDTR) and interrupt descriptor table register (IDTR) expand to 10 bytes so that they can hold a full 64-bit base address. The local descriptor table register (LDTR) and the task register (TR) also expand to hold a full 64-bit base address. Focus: 64-bit sub-mode of Intel’sRFLAGS IA-32e mode Physical Address Code, Data or Stack Control Register Segment (Base =0) Basic Program Execution Registers Address Space Linear Address CR8 Task-State 2^64 -1 CR4 Segment Selector Segment (TSS) CR3 Sixteen 64-bit General-Purpose Registers CR2 Register Registers CR1 CR0 Global Descriptor Task Register Table (GDT) Six 16-bit Interrupt Handler Segment Registers Segment Sel. Seg. Desc. Registers Code NULL Interrupt TR TSS Desc. Stack 64-bits RFLAGS Register Vector Seg. Desc. Interrupt Descriptor 64-bits RIP (Instruction Pointer Register) Table (IDT) Seg. Desc. Interr. Handler Code Interrupt Gate Current TSS FPU Registers LDT Desc. Stack Interrupt Gate GDTR Eight 80-bit Floating-Point IST Data Registers Trap Gate Registers 0 Local Descriptor Exception Handler Table (LDT) Code NULL Stack IDTR Call-Gate Seg. Desc. 16 bits Control Register Segment Selector Call Gate 16 bits Status Register Protected Procedure 16 bits Tag Register XCR0 (XFEM) Code LDTR NULL Stack Opcode Register (11-bits) 64 bits FPU Instruction Pointer Register Linear Address Space Linear Address 64 bits FPU Data (Operand) Pointer Register PML4 Dir. Pointer Directory Table Offset MMX Registers Linear Addr. PML4 Pg. Dir. Ptr. Page Dir. Page Table Page Eight 64-bit MMX Registers Registers Physical PML4. Pg. Dir. Page Tbl Addr. Entry Entry Entry XMM Registers 0 This page mapping example is for 4-KByte pages CR3* and 40-bit physical address size. *Physical Address Sixteen 128-bit XMM Registers Registers Figure 2-2. System-Level Registers and Data Structures in IA-32e Mode 32-bits MXCSR Register 2.1.1 Global and Local Descriptor Tables When operating in protected mode, all memory accesses pass through either the global descriptor table (GDT) or an optional local descriptor table (LDT) as shown in Figure 2-1. These tables contain entries called segment Figure 3-2. 64-Bit Mode Executiondescriptors. Environment Segment descriptors provide the base address of segments well as access rights, type, and usage information. Model Development Each segment descriptor has an associated segment selector. A segment selector provides the software8 that/27 uses Source: Intel itManuals with an index into the GDT or LDT (the offset of its associated segment descriptor), a global/local flag (deter- 3.3 MEMORY ORGANIZATION mines whether the selector points to the GDT or the LDT), and access rights information. The memory that the processor addresses on its bus is called physical memory. Physical memory is organized as a sequence of 8-bit bytes. Each byte is assigned a unique address, called a physical address. The physical address space ranges from zero to a maximum of 236 − 1 (64 GBytes) if the processor does not support Intel Vol. 3A 2-3 Vol. 1 3-5 PROTECTION — TSS — The DPL indicates the numerically highest privilege level that the currently executing program or task can be at and still be able to access the TSS. (This is the same access rule as for a data segment.) • Requested privilege level (RPL) — The RPL is an override privilege level that is assigned to segmentPROTECTION selectors. It is stored in bits 0 and 1 of the segment selector. The processor checks the RPL along with the CPL BASIC EXECUTION ENVIRONMENT to determine if access to a segment is allowed. Even if the program or task requesting access to a segment has Thesufficient center (reserved privilege tofor access the most the privileged segment, code,access data, is denied and stacks) if the RPL is used is not for of the sufficien segmentst privilege containing level. the That critical is, software,if the RPL usually of a segment the kernel selector of an isoper numericallyating system. greater Outer than rings the are•CPL, usedDebug the RPLfor less overridesregisters critical the software. — CPL,Model Debug and (Systems viceregisters versa. that expand Development to 64 bits. See Chapter 17, “Debug, Branch Profile, TSC, and The RPL can be used to insure that privileged code does not access a segment on behalf of an application use only 2 of the 4 possible privilege levels should use levels 0 and 3.)Quality of Service,” in the Intel® 64 and IA-32 Architectures Software Developer’s Manual, Volume 3A.