1

Hardware Security MechanismsKrste AsanovicU.C. Berkeley

August 20, 2009

Target Systems

Trusted app wants to use functionality in legacy libraries and legacy OS

Untrusted interactionsUntrusted interactionsTrusted interactionsTrusted interactions

HardwareHardware

Thin Trusted HypervisorThin Trusted Hypervisor

Legacy OSLegacy OS

Trusted Trusted AppApp

Legacy Legacy AppsApps

Legacy Legacy LibrariesLibraries

Trusted Trusted ServiceService

Trusted Trusted AppApp

I/OI/O

Custom OSCustom OSCustom OSCustom 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 SupportPartition 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

CPUCPU

L1L1

L2L2BankBank

DRAMDRAM

CPUCPU

L1L1

L2L2BankBank

DRAMDRAM

CPUCPU

L1L1

L2L2BankBank

DRAMDRAM

CPUCPU

L1L1

L2L2BankBank

DRAMDRAM

CPUCPU

L1L1

L2L2BankBank

DRAMDRAM

L2 InterconnectL2 Interconnect

DRAM & I/O DRAM & I/O InterconnectInterconnect

Partition 2Partition 2Partition 1Partition 1 Protected Protected Shared Shared MemoryMemory

5

Wirelessradio

Memory

Media Player NetworkDriver

Filesystem

Browser

Video decoder GUI

WindowsVM

De-scheduled Partitions

Space-Time partitioning basis for manycore OS

QoS AllocationsQoS Allocations

System Structure

6

Hyp

ervisor

Kern

el

Partition Management

Layer

Hardware Partitioning Mechanisms

CPUsPhysical Memory

InterconnectBandwidth

CachePerformance

Counters

Partition Mechanism

Layer(Trusted)

ApplicationOr

Legacy OS

LocalScheduler

Library OS Functionality

ConfigureHW-supportedCommunication

MessagePassing

Configure Partition Resources enforced by

HW at runtime

PartitionAllocator

PartitionScheduler

Comm.Reqs

SchedReqs.

PartitionResizing

Callback API

Res.Reqs.

Fine-Grained Memory Protection

Main lib11 2

Memory

Addresses

0x000…

0xFFF…

lib2 lib33 4

No perm

Read-write

Read-only

Execute-read

Multiple protection domains

• Selectively enable Selectively enable legacy library access legacy library access to main app data.to main app data.

• Can also restrict Can also restrict legacy OS accesslegacy OS access

• Permissions Permissions established with established with hypercalls (direct hypercalls (direct trap to hypervisor)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

HardwareHardware

Thin Trusted HypervisorThin Trusted Hypervisor

Legacy OSLegacy OS

Trusted Trusted AppApp

Legacy Legacy AppsApps

Legacy Legacy LibrariesLibraries

Trusted Trusted ServiceService

Trusted Trusted AppApp

I/OI/O

Custom OSCustom OSCustom OSCustom OS

Hardware PartitionsHardware Partitions

Fine-Grained Fine-Grained Memory Memory

ProtectionProtection

Secure User-Secure User-Level MessagesLevel 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

SoftwareSimulator $2,000 0.1 - 1 1

RAMP Gold $2,000 + $750 50 - 100 100

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?