1 / 22

Hardware Support for Isolation

Krste Asanovic U.C. Berkeley MURI “DHOSA” Site Visit April 28, 2011. Hardware Support for Isolation. SVA. Cryptographic secure computation. e.g., Enforce properties on a malicious OS. Binary translation and emulation. Data-centric security.

hani
Download Presentation

Hardware Support for Isolation

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. Krste Asanovic U.C. Berkeley MURI “DHOSA” Site Visit April 28, 2011 Hardware Support for Isolation

  2. 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 Hardware support for isolation Secure servers e.g., Prevent dataexfiltration Dealing with malicious hardware web-based architectures HARDWARE SYstem architectures

  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 Hardware support for isolation Secure servers e.g., Prevent dataexfiltration Dealing with malicious hardware web-based architectures HARDWARE SYstem architectures

  4. Target Scenario Valuable Data Approved information flow Undesirable information leak Normal Execution Environment Secure Execution Environment Desirable App Noncritical App UntrustedOS UntrustedOS TrustedHypervisor TrustedHardware

  5. Hardware Isolation Techniques • Fine-grain Memory Protection • Dynamic Information Flow Tracking • Secure Messaging • Timing Isolation

  6. Hardware Isolation Techniques • Fine-grain Memory Protection • Dynamic Information Flow Tracking • Secure Messaging • Timing Isolation

  7. Many shared resources: Last-level Cache Interconnect Last-Level Cache Capacity DRAM & I/O Interconnects CPU CPU CPU CPU CPU L1 L1 L1 L1 L1 L2 Interconnect L2 Bank L2 Bank L2 Bank L2 Bank L2 Bank DRAM & I/O Interconnect DRAM DRAM DRAM DRAM DRAM Modern Multicore Systems All shared hardware resources can be used to build high-bandwidth timing-based covert channels

  8. Timing-Based Covert Channel using shared interconnect • Sending core modulates traffic on shared interconnect (e.g., writes to given memory location over bus) Writes by sending core Covert “1” Covert “0” • Receiving core attempts to saturate bus with requests and observes how much bandwidth is available Writes by receiving core Time Time Unit message time on interconnect

  9. Multicore & Timing-Based Attacks • Concurrent execution on different cores and high-performance on-chip interconnect allows higher-bandwidth covert channels • Ability to quickly train attacker using timing gathered when running on a subset of machine • E.g., calibrate using two unsecured cores, before using between secured and unsecured cores.

  10. Partition can contain own: Cores L1 and L2 $ capacity Off-chip DRAM bandwidth On-chip interconnect bandwidth allocation CPU CPU CPU CPU CPU L1 L1 L1 L1 L1 L2 Interconnect L2 Bank L2 Bank L2 Bank L2 Bank L2 Bank DRAM & I/O Interconnect DRAM DRAM DRAM DRAM DRAM Partition 2 Partition 1 Hardware Partitioning for Timing Isolation How to isolate while retaining high efficiency?

  11. Interconnect Partitioning • Off-chip DRAM bandwidth and on-chip interconnect bandwidth are among most expensive resources in system. • Static partitioning would require dedicated, and hence under-utilized, interconnect. • Multiplexing interconnect among multiple requesters increases system efficiency, but enables timing attacks.

  12. Secure Interconnect Multiplexing:Time-Division Multiplexing • Statically allocate bus time slots between different cores. Repeating fixed allocation within frame Time Secure traffic allocation (2/3) Insecure traffic allocation (1/3)

  13. Secure Interconnect Multiplexing:Time-Division Multiplexing Ifone corecannot use slot, it is left idle even if other core has traffic to send. Cores cannot see each other’s traffic level. Secure, but wasteful. Idle slots Secure traffic allocation (2/3) Insecure traffic allocation (1/3) Time

  14. Secure Interconnect Multiplexing:One-Sided Bandwidth Recycling • Allow secure traffic to use unclaimed insecure bus slots, but not vice versa. • Insecure app cannot view timing of secure app. Recycled idle slots Secure traffic allocation (2/3) Insecure traffic allocation (1/3) Time

  15. Real System Interconnects • Multihop interconnection networks • Rings, meshes • Cache-coherence protocols • Single load or store instruction can generate dozens of individual interconnect messages • Multiple interconnection networks for memory system • Separate physical networks for initial requests, snoop traffic, responses, data payloads

  16. Intel Sandy Bridge

  17. Globally Synchronized Frames for Memory System Extending our earlier work on GSF for point-point networks: • Divide time into discrete “frames”. • Each core receives allocation of credits each frame timeto perform memory operations. • Credit is permission to cause worst-case traffic on every network for one memory operation. • Reclaim unused credits to boost bandwidth. • For secure system, only secure cores reclaim unused bandwidths.

  18. RAMP Gold: Initial version models 64 cores of SPARC v8 with shared memory system on $750 board FPGA Emulation of Hardware Concepts

  19. GSFm Status on RAMP Gold • Working GSF-style memory bandwidth reservation system on RAMP Gold • Working Tessellation OS partition-based operating system can adjust allocations to control bandwidth partitioning • Also partitions cores and cache capacity. • Ongoing: investigating hardware cost/efficiency loss of asymetric bandwidth recycling.

  20. Adoption path • Hardware vendors already considering partitioning support for performance isolation • Real-time guarantees (e.g., media playback) • Service-level guarantees (e.g., cloud computing) • Performance tuning (e.g., repeatable timing) • Small tweak could also prevent timing channels

  21. Other HardwareIsolation Mechanisms in Progress Fine-grained memory protection and protection domains Fine-grain dynamic information flow tracking User-level protected message passing Direct protected communication between trusted app components and trusted services

  22. Questions?

More Related