Hypervisor-Protected System Architecture

1. Hypervisor-Protected System Architecture App. App. App. Protected OS Hypervisor Hardware Phy Mem Adv MMU Kernel Key Code KPT SPT IOMMU Data SecVisor Adv DEV Vulnerability 1: Adversary gives eXe privilege to code stored in user memory SPT X User Mem X KPT Sync Kernel Code W Kernel Data W Vulnerability 2: Adversary adds writable alias to kernel code Automated Verification of a Security Hypervisor with a Realistic Hardware Model Jason Franklin, Sagar Chaki, Anupam Datta, Carnegie Mellon University Motivation Overview • Systems with small trusted computing bases (TCBs) open possibility for automated security verification of systems • Example: SecVisor - a 3kLOC security hypervisor designed to guarantee only user-approved code executes with kernel privilege [Seshadri et al. SOSP ‘07] • Goals: Develop tools and techniques to automatically verify security of systems that utilize memory protection mechanisms • Design Analysis: Model check SecVisor’s design, find and repair two vulnerabilities, and verify repaired design • Towards Realistic Hardware Models: Exploit system structure to prove security of arbitrarily large model (measured in terms of page table entries (PTEs)) by verifying only small model (with 1 PTE) • Implementation Analysis: In-progress work includes verifying SecVisor’s C source code. Approach includes development of C-model of x86 hardware virtualization extensions, bit-precise adversarial model checker, and new techniques for scalable verification Security hypervisor provides layer of verifiable protection <10kLOC Narrow interface Tractability vs. Fidelity • To make verification tractable, system model and adversary are restricted to unrealistically small number of PTEs • Thus, these results do NOT demonstrate absence of attacks for realistic systems • Exploit structure of memory protection mechanisms and access control properties to extend verification to realistic memory models. We prove: Design Analysis • Model: Develop formal models of SecVisor, hardware platform, and adversary. Total Verification Model Size = SecVisor Model + HW Model + Adversary Model • Security Property: In every reachable state of the system, W X permissions hold on page table and Device Exclusion Vector (DEV) implying only user-approved code executes with kernel privilege • Vulnerabilities: Model checker identified two vulnerabilities in shadow page table (SPT) design that carry over to implementation. Both vulnerabilities caused by missing checks in SPT synchronization code • Verification: After adding additional checks to synchronization code, the repaired system satisfied security property [Tech. Report CMU-Cylab-08-008] SmallWorld Theorem (SWT) If SecVisor’s security properties are violated in a arbitrarily large but finite memory model then they are violated in a small memory model • SWT implies that a small memory model is sufficient for verification of SecVisor’s access control-based memory protection. It generalizes to other secure systems: Principle of Efficiently-Verifiable Memory Protection: Small World Language and Logic (SWL) codifies the design principle behind efficiently-verifiable memory protection. Any system expressible in SWL satisfies the Small World Theorem and hence has an efficiently-verifiable memory protection subsystem. Source Code Verification • In-progress work includes verifying SecVisor’s C source code. Approach includes development of C-model of x86 hardware virtualization extensions, bit-precise adversarial model checker, and new techniques for scalable verification: • Secure Composition: Verifying separate stages of systems (e.g., bootstrap and runtime) and securely compose the resulting verified subsystems • Security Skeleton Extraction: Automatically extract just the security-relevant code, thereby greatly reducing verification costs