1 / 11

Hardware Security Mechanisms

Krste Asanovic U.C. Berkeley August 20, 2009. Hardware Security Mechanisms. Target Systems. Trusted app wants to use functionality in legacy libraries and legacy OS. Untrusted interactions. Trusted interactions. Legacy Apps. Trusted App. Legacy Libraries. Legacy OS. Trusted Service.

jasia
Download Presentation

Hardware Security Mechanisms

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 August 20, 2009 Hardware Security Mechanisms

  2. Target Systems Trusted app wants to use functionality in legacy libraries and legacy OS Untrusted interactions Trusted interactions Legacy Apps Trusted App Legacy Libraries Legacy OS Trusted Service Trusted App Custom OS Custom OS Thin Trusted Hypervisor I/O Hardware

  3. Hardware Security Mechanisms Functional isolation and QoS performance isolation through hardware partitioning E.g., isolate legacy OS from custom trusted OS and services Fine-grained memory protection and protection domains Isolated trusted portion of application from untrusted legacy libraries (and legacy OS?) User-level protected message passing Direct protected communication between trusted app components and trusted services

  4. Hardware Partitioning Support Partition can contain own cores, L1 and L2 $/RAM, DRAM, and interconnect bandwidth allocation Inter-partition communication through protected shared memory and user-level messages Benefits: Security Efficiency (fewer layers, custom OS) Enables new exposed HW primitives Performance isolation/predictability Robustness to faults/errors 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 Protected Shared Memory

  5. Space-Time partitioning basis for manycore OS Media Player Network Driver Wireless radio GUI Video decoder QoS Allocations Windows VM Browser Filesystem Memory De-scheduled Partitions 5

  6. System Structure Application Or Legacy OS Local Scheduler Library OS Functionality Partition Resizing Callback API Res. Reqs. Sched Reqs. Comm. Reqs Partition Management Layer Partition Scheduler Partition Allocator Hypervisor Kernel Partition Mechanism Layer (Trusted) Configure Partition Resources enforced by HW at runtime Configure HW-supported Communication Interconnect Bandwidth Message Passing Cache Physical Memory CPUs Performance Counters Hardware Partitioning Mechanisms 6

  7. Fine-Grained Memory Protection Memory Addresses 0xFFF… • Selectively enable legacy library access to main app data. • Can also restrict legacy OS access • Permissions established with hypercalls (direct trap to hypervisor) No perm Read-write Read-only Execute-read 0x000… 1 2 3 4 Main lib1 lib2 lib3 Multiple protection domains

  8. Secure User-Level Messaging Allow trusted code to directly send messages to trusted services or other trusted applications Message channels established through hypercalls and buffering set aside in memory Message send is atomic append-only to queue (cannot overwrite earlier message) Message receive is atomic dequeue Needs to interact with software schedulers at each end

  9. Target Systems Trusted app wants to use functionality in legacy libraries and legacy OS Fine-Grained Memory Protection Hardware Partitions Secure User-Level Messages Legacy Apps Trusted App Legacy Libraries Legacy OS Trusted Service Trusted App Custom OS Custom OS Thin Trusted Hypervisor I/O Hardware

  10. FPGA Emulation of Hardware Concepts Rapid accurate simulation of manycore security ideas using FPGAs RAMP Gold: Initial version models 64 cores of SPARC v8 with shared memory system on $750 board

  11. Why Hardware? Performance matters Energy matters Legacy codes “we lost the source” Can’t recompile Someone else’s source code “QA costs $5M” Multicore adds new security concerns Speed up or reduce size of trusted software There will always be hardware at bottom of stack - how should it change for security?

More Related