1 / 22

Secure Virtual Architecture

Secure Virtual Architecture. John Criswell, Andrew Lenharth, Dinakar Dhurjati, Arushi Aggarwal, Will Dietz, and Vikram Adve University of Illinois at Urbana-Champaign. Outline. Background Results to Date Controlling the OS Full System Recovery Ongoing Work Secure Application Computation.

duard
Télécharger la présentation

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, Andrew Lenharth, Dinakar Dhurjati, Arushi Aggarwal, Will Dietz, and Vikram Adve University of Illinois at Urbana-Champaign

  2. Outline • Background • Results to Date • Controlling the OS • Full System Recovery • Ongoing Work • Secure Application Computation 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. Applications Need a Hero • Enforce application-specific security policies • Confidentiality • Data-centric application/user policies • But Malicious OS can examine/modify any data in memory • Need an agent to control a potentially malicious OS • Need something below the OS! Hardware! Protect me from this malicious OS! Secure Virtual Architecture Application Operating System Sorry, application. You’re on your own Hardware

  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 and Transformations • Type Inference • Points-to Analysis • Automatic Pool Allocation Secure Virtual Architecture

  8. Outline • Background • Results to Date • Controlling the OS • Full System Recovery • Ongoing Work • Secure Application Computation Secure Virtual Architecture

  9. Hardware SVA-OS • API implemented as a run-time library linked into the kernel • Implements interface between system code and hardware • Provides key software/hardware functionality • Like a ukernel, only better • Sufficiently low-level to support multiple operating systems • Sufficiently high-level to enable strong analysis Secure Virtual Architecture Linux + SVA-OS Virtual ISA SVM Native ISA SVA can control the OS!

  10. Safe Software/Hardware Interaction Secure Virtual Architecture

  11. Summary: A Secure Foundation • Strong memory safety enforcement == full SVA guarantees • 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

  12. Operating System Recovery • Recovery Domains: An Organizing Principle for Recoverable Operating Systems • ASPLOS ‘09: Andrew Lenharth, Vikram Adve, and Samuel T. King • Basic Idea: treat OS system calls as transactions • When an error is detected roll back state and re-exec syscall Secure Virtual Architecture

  13. Outline • Background • Results to Date • Controlling the OS • Full System Recovery • Ongoing Work • Secure Application Computation Secure Virtual Architecture

  14. Secure Memory • Only an application can access its secure memory • SVA prevents the OS from accessing the secure memory • Disallow OS from mapping the secure memory Application Virtual Pages Secure Virtual Architecture OS Virtual Pages Physical Page Frames Application Regular Memory Application Secure Memory OS Kernel Memory

  15. Secure Memory is Great, But… • Unfettered OS can indirectly access secure memory • E.g., Signal handler dispatch and context switching • Secure Memory is difficult to use • Pointers to secure memory must also be in secure memory. • Program itself can leak data unintentionally Secure Virtual Architecture

  16. Secure Memory Outline • What we’re working on now: basic secure memory • Key: maintain CFI for application, protect data • What we’ll be working on soon: usable secure memory • Use compiler to help with difficult to reason about properties Secure Virtual Architecture

  17. Preventing Access to Program Code and Stacks Application Kernel • OS cannot modify or remap: • Application Stack • Application Code • Works because SVA controls: • Loads/stores • MMU configuration • Protects application CFI • OS cannot get application to bypass run-time checks inserted by SVA • OS cannot cause application to execute arbitrary code Code: Secure Virtual Architecture Stack:

  18. Interacting with the OS • Prevent OS could from modifying saved program state • CPU state saved on syscall or interrupt • CPU state saved on context switch • Ensure that OS restores correct state • Context Switch • Memory access still an open challenge • Simple solution: allow heap access, promote stack buffers to heap • More complex: analyze application and OS together Secure Virtual Architecture OS is Master OS is Untrusted Partner Application Application Operating System Operating System

  19. Asynchronous Program Invocation and Signal Handling • SVA-OS has instruction for modifying application stack • Add checks to it to ensure function is a signal handler • SVA can determine which functions are arguments to syscalls • Ensure OS restores correct application state on sigreturn() Application Stack Application Stack Application Stack Secure Virtual Architecture sva_push_func sva_load_icontext Original Application Registers Application Registers After Signal Handler Dispatch

  20. Basic Usable Secure Memory • Pointers to secure memory objects must be in secure memory • Points-to graph can find such pointers • Move them to secure memory Pointer Secure Memory Object Secure Virtual Architecture Insecure Memory Object

  21. Secure Memory and Non-interference • Computations using secure memory do not use insecure memory • Computations using insecure memory do not use secure memory • Import/export instructions moving data to/from secure memory • Allows intentional breaking of non-interference • Ensures OS does not affect computations Secure Virtual Architecture

  22. Conclusions • SVA provides a secure foundation • Control over the OS • Recovery from detected safety violations • We have: • Automated recovery from run-time safety violations • Initial design of secure memory • Ongoing work: • Implementation of secure memory • Design of secure memory usability enhancements if time permits Secure Virtual Architecture

More Related