110 likes | 237 Views
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.
E N D
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 Trusted App Custom OS Custom OS Thin Trusted Hypervisor I/O Hardware
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
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
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
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
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
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
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
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
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?