Secure Virtual Architecture

1. Secure Virtual Architecture Secure Virtual Architecture John Criswell, Arushi Aggarwal, Andrew Lenharth, Dinakar Dhurjati, and Vikram Adve University of Illinois at Urbana-Champaign

2. Outline • Background • Current Work • Future Work Secure Virtual Architecture

3. SVA Cryptographic secure computation e.g., Enforce properties on a malicious OS Binary translation andemulation Data-centric security e.g., Enable complex distributed systems, with resilience to hostile OS’s Formal methods Secure browser appliance transformation Secure Virtual Architecture Hardware support for isolation Secure servers e.g., Prevent dataexfiltration Dealing with malicious hardware web-based architectures HARDWARE SYstem architectures

4. Wouldn’t It Be Great? • Enforce information flow policy • Confidentiality • Data-centric policy created by application/user • Malicious OS can examine/modify any data in memory • Need to control OS memory operations • Keep system running when a safety violation is detected Secure Virtual Architecture Process 1 Process 2 Operating System Memory

5. Hardware Secure Virtual Architecture Commodity Applications + OS • Compiler-based virtual machine • Uses sophisticated compiler analysis & transformation techniques • Virtual instruction set • Typed virtual instruction set enables sophisticated program analysis • Special instructions for OS kernel support • Provide safe execution environment for commodity software • Supports unmodified C/C++ applications • Supports commodity operating systems (e.g., Linux) Virtual ISA Compiler + VM Native ISA Secure Virtual Architecture

6. SVA Safety Guarantees • Dangling pointers & non-type-safe objects do not compromise other guarantees • Strongest memory safety for C sans garbage collection Secure Virtual Architecture

7. What’s the Secret Sauce? • Run-time Checks • Load/Store Checks • Bounds Checks • Illegal Free Checks • Indirect Call Checks • Static Analysis • Type Inference • Points-to Analysis Secure Virtual Architecture

8. Outline • Background • Current Work • Future Work Secure Virtual Architecture

9. Safe Software/Hardware Interaction Secure Virtual Architecture

10. A Secure Foundation • Strong memory safety enforcement • Even for low level OS code! • Can rely on static analysis results to hold at run-time • Enforces safety properties on applications and OS kernel code Safety enforced despite hostileOS Code! Secure Virtual Architecture

11. Current Work • Information Flow for C • Improved Type Inference • Recovery from Safety Violations Secure Virtual Architecture

12. CIF: C Information Flow Compiler • Experimental information flow infrastructure for C/C++ • Explicit information flow on memory object granularity • Properly joins (meets) labels for computation results • Based on SVA • Memory safety errors cannot violate safety guarantees • Can reuse SVA infrastructure for optimization Process Secure Virtual Architecture Data Memory Object Meet Data

13. SVA Controls Information Flow • SVA controls • Memory access • MMU configuration • Information Flow • Uniform monitoring • SVA enforces policies • Not the OS Process 1 Process 2 Operating System SVA Virtual Machine Secure Virtual Architecture Memory

14. Improving Type Safety in SVA • Benefits • Better pointer disambiguation due to improved field sensitivity • Better safety • More static type safety yields more precise run-time safety guarantees • Better performance • Type-safe objects do not need load/store checks Secure Virtual Architecture

15. Type Safety Enhancements • Tracking types at byte-offsets • Permit a subset of a memory object to be type safe • Supports C++ class hierarchy sub-typing • Identifying C library functions and allocator wrappers • Static code transformations to improve inference results • Cloning of address-taken functions for use in direct calls • Clone functions that take embedded structures from incompatible types Secure Virtual Architecture

16. Static Type Safety SPEC 2000 Secure Virtual Architecture

17. Static Type Safety SPEC 2006 Secure Virtual Architecture

18. Outline • Background • Current Work • Future Work Secure Virtual Architecture

19. Dynamic Type Tracking in SVA • Track types stored to memory at run-time • Used for memory operations that cannot be proven safe statically • Byte granularity tracking • Fine grained tracking of fields in structures • Check type of data when loading from memory Secure Virtual Architecture

20. Conclusions • SVA provides a secure foundation • We have: • Infrastructure for secure information flow • Improved type inference • Automated recovery from run-time safety violations • In the pipeline: • Secure information flow to enforce safety sans OS support • Dynamic type tracking Secure Virtual Architecture Heeeeere’s Andrew!