1 Hardware Security Mechanisms Krste Asanovic U.C. Berkeley August 20, 2009

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

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 L1 L2Bank DRAM CPU L1 L2Bank DRAM CPU L1 L2Bank DRAM CPU L1 L2Bank DRAM CPU L1 L2Bank DRAM L2 Interconnect DRAM & I/O Interconnect Partition 2 Partition 1 Protected Shared Memory

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

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

Fine-Grained Memory Protection Mainlib1 12 Memory Addresses 0x000… 0xFFF… lib2lib3 34 No perm Read-write Read-only Execute-read Multiple protection domains Selectively enable legacy library access to main app data.Selectively enable legacy library access to main app data. Can also restrict legacy OS accessCan also restrict legacy OS access Permissions established with hypercalls (direct trap to hypervisor)Permissions established with hypercalls (direct trap to hypervisor)

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 Hardware Thin Trusted Hypervisor Legacy OS Trusted App Legacy Apps Legacy Libraries Trusted Service Trusted App I/O Custom OS Hardware Partitions Fine-Grained Memory Protection Secure User- Level Messages

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 Cost Performance (MIPS) Simulations per day Software Simulator $2, RAMP Gold$2,000 + $

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?