1 / 20

Secure Virtual Architecture

Secure Virtual Architecture. John Criswell, Arushi Aggarwal, Andrew Lenharth, Dinakar Dhurjati, and Vikram Adve University of Illinois at Urbana-Champaign. Outline. Background Current Work Future Work. SVA. Cryptographic secure computation.

george
Download Presentation

Secure Virtual Architecture

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  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!

More Related