220 likes | 370 Vues
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.
E N D
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 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
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
Target Scenario Valuable Data Approved information flow Undesirable information leak Normal Execution Environment Secure Execution Environment Desirable App Noncritical App UntrustedOS UntrustedOS TrustedHypervisor TrustedHardware
Hardware Isolation Techniques • Fine-grain Memory Protection • Dynamic Information Flow Tracking • Secure Messaging • Timing Isolation
Hardware Isolation Techniques • Fine-grain Memory Protection • Dynamic Information Flow Tracking • Secure Messaging • Timing Isolation
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
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
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.
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?
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.
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)
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
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
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
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.
RAMP Gold: Initial version models 64 cores of SPARC v8 with shared memory system on $750 board FPGA Emulation of Hardware Concepts
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.
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
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