Towards an Open-Source, Formally-Verified Secure Processor Srini - PowerPoint PPT Presentation

Towards an Open-Source, Formally-Verified Secure Processor Srini Devadas Massachusetts Institute of Technology

Architectural Isolation of Processes Fundamental to maintaining correctness and privacy! 2

Performance Dictates Microarchitectural Optimization Isolation Breaks Because of Shared Microarchitectural State! 3

Building a Transmitter Domain of Victim Attacker Transmitter Receiver Access Channel Secret Secret Pre-existing (RSA conditional execution example) Written by attacker (Meltdown) Synthesized out of existing victim code by attacker (Spectre) 4

Side Channels Gone Wild! • Real systems: large, complex, cyberphysical (not secure) sharing! sharing! • Introducing a spy: CPU DRAM Ctrl. DRAM L1 $ Thread L2 $ OS L3 $ App Main Chipset users! sharing! board Hypervisor, Bios Disk Network admins! vendors! admins! users! 5

Philosophy Build enclaves on an enclave platform, not just processes 6

Enclaves strengthen the process abstraction • Processes guarantee isolation of memory • Enclaves provide a stronger guarantee – No other program can infer anything private from the enclave program through its use of shared resources or shared microarchitectural state • Largely decouple performance considerations from security • Minimally invasive hardware changes • Provable security under chosen threat model 7

A Typical Computer Trusted Computing Base Software… ! … Running on hardware ! TRUSTED ! (Ring 3) ! CPU ! App ! App ! Secure App ! DRAM Ctrl. ! ! L1 $ ! DRAM ! Thread ! L2 $ ! Privelege ! TRUSTED ! L3 $ ! OS Kernel (Ring 0) ! Hypervisor (Ring 0, VMX root) ! Main ! Chipset ! board ! BIOS (SMM) ! Disk ! Network !

Single-Chip Secure Processor: Shrink the TCB • From Edward Suh’s ICS 2003 Talk Trusted Protect Protected Environment Software I/O Identify Memory • Enclave assumes trusted hardware + trusted software “monitor” • Operating system is untrusted 9

Enclave Lifecycle (simplified) Enclave Untrusted binary image software (OS) Load enclave � � � Create enclave, Seal Grant resources enclave Enclave Enclave Enclave Enclave Enclave binary binary image image Enclave has a Enclave can no measurement for longer be modified 10 attestation from outside

Enclave Lifecycle (simplified) Enclave Untrusted binary image software (OS) Platform erases (flushes) Load � sensitive state Enter enclave � � � enclave Create enclave, Seal Grant resources enclave (enclave executes in a strongly isolated environment) � Exit enclave 11

Strong Isolation Goal • Any attack by a privileged attacker on the same machine as the victim that can extract a secret inside the victim enclave, could also have been run successfully by an attacker on a different machine than the victim. – No protection against an enclave leaking its own secrets through its public API. • Three strategies for isolation: Spatial isolation, temporal isolation and cryptography 12

Sanctum Design Victor Costan, Ilia Lebedev Sanctum: Minimal Hardware Extensions for Strong Software Isolation

Software Stack Measurement Root Machine Security Monitor Hypervisor Hypervisor Enclave multiplexing Operating System Supervisor Enclave management Host Application Enclave Enclave setup User Enclave syscall shims Sanctum-aware runtime Non-sensitive code and data Sensitive code and data

Software Stack Measurement Root Machine Security Monitor Hypervisor Hypervisor Enclave multiplexing Operating System Supervisor Enclave management Host Application Enclave Enclave setup User Enclave syscall shims Sanctum-aware runtime Non-sensitive code and data Sensitive code and data

Target: multi-core processor (no hyperthreading, no speculation) Core Core DDR3 L2 Cache L2 Cache QPI Link Channel CBox CBox QPI Ring to L3 Cache L3 Cache Packetizer QPI L3 Cache Slice Slice Home Memory Agent Controller L3 Cache L3 Cache UBox Ring to Slice Slice PCIe I/O Controller CBox CBox L2 Cache L2 Cache PCIe Lanes Core Core

Microarchitectural State Isolation in Sanctum Enclaves • Resources exclusively granted to an enclave, and scheduled at the granularity of process context switches are isolated temporally – Register files, branch predictors, private caches, and private TLBs • Resources shared between processes on- demand, with arbitrarily small granularity are isolated spatially by partitioning – Shared caches and shared TLBs 17

Operating System Manages Page Tables Address Physical Virtual Translation Address Space Address Space Virtual Physical Mapping Address Address System bus Page Software DRAM Tables

Practical Software Attack on SGX “Simulators” • Microsoft Research, IEEE S&P 2015: Exploit no-noise side channel due to page faults 19

Page Table Isolation Physical Memory Enclave B Virtual Enclave A Virtual OS region Address Space Address Space OS page tables Host application Host application space Enclave A region space Enclave A page tables EVRANGE A EVRANGE B Enclave B region Enclave B page tables Host application Host application space space OS region Enclave A region

Partitioning to Prevent Timing Attacks Memory Address Address Tag Set Index Line Offset n-1…s+l s+l-1…l l-1…0 Enclave Set 0, Way 0 Set 0, Way 1 … Set 0, Way W-1 Set 1, Way 0 Set 1, Way 1 … Set 1, Way W-1 ⋮ ⋮ ⋱ ⋮ OS Set i, Way 0 Set i, Way 1 … Set i, Way W-1 ⋮ ⋮ ⋱ ⋮ Set S-1, Way 0 Set S-1, Way 1 … Set S-1, Way W-1 21

Page Coloring Address bits covering the maximum addressable physical space of 2 MB Address bits used by 256 KB of DRAM Cache Set Index DRAM Stripe DRAM Region Cache Index Index Line O ff set 20 18 17 15 14 12 11 6 5 0 Cache Tag Page O ff set Physical page number (PPN)

Normal DRAM Sanctum DRAM page colors page colors / regions 0 0 Page Colors LLC set colors = DRAM Regions MEMTOP MEMTOP Region 0 Region 1 Region 2 Region 3 Region 4 Region 5 Region 6 Region 7

Normal DRAM Sanctum DRAM Page Colors page colors page colors / regions 0 0 = LLC set colors DRAM Regions A little bit-shifting gets us a large contiguous DRAM region MEMTOP MEMTOP Region 0 Region 1 Region 2 Region 3 Region 4 Region 5 Region 6 Region 7

Sanctum Secure Processor No Speculation, No Hyperthreading RISCV Rocket Core, Changes required by Sanctum (+ ~2% of core) Also requires 9 new config registers

Formally Verifying Enclaves Pramod Subramanyan, Rohit Sinha, Ilia Lebedev, Sanjit Seshia A Formal Foundation for Secure Remote Execution of Enclaves

Rigorously modeling the adversary Adversary := set of ops an attacker can use to tamper with or observe enclave state. Any combination of these can be used at any time. Threat model := ∪ (observation function, tamper function, model initial state) 27

Abstract Enclaves An entity that can perform a well-defined set of TAP actions, and has these properties: Measurement := Different enclaves have different measurements (also inverse) Integrity := Modelled attacker cannot affect enclave state Confidentiality := Modelled attacker cannot observe enclave state 28

Proving Statements with the TAP There is no “processor”. There aren’t cores. The proof describes a CFG with “forks”. Proof searches this graph for a path that violates an invariant. Do an attacker action Init Check operations invariants Do a victim action Threat model = TAP API + space of attacker actions 29

Refinement Proofs • SGX refines TAP, i.e., every operation is SGX is an operation in TAP • Caveat: For a limited observation function • Sanctum refines TAP for a more powerful observation function 30

Sanctum Status and Current Limitations • We have built an open-source Sanctum based on the RISC-V ISA – Low performance and area overhead to support enclaves – Ongoing formal verification effort • Sanctum is an academic, lightweight processor • Apply its design philosophy to speculative out-of-order (OOO) processors, which need to protect against Spectre-style attacks 31

MI6 Design Thomas Bourgeat, Ilia Lebedev, Andrew Wright, Sizhuo Zhang, Arvind MI6: Secure Enclaves in a Speculative Out-of-Order Processor

RiscyOO Processor ROB Commit ALU pipeline Reg Reg Issue Exec Fetch ALU IQ Bypass Read Write Physical Reg File MEM pipeline Rename Rename Reg Addr Update Issue MEM IQ Table Read Calc LSQ Speculation L1 D TLB Manager Load-Store Unit Epoch Deq LSQ (LQ + SQ) Manager Resp Issue Resp Issue Store Scoreboard Ld Ld St St Buffer Front-end L1 D$ 33 Last Level Cache

RiscyOO Processor ROB Commit ALU pipeline Reg Reg Issue Exec Fetch ALU IQ Bypass Read Write Not speculating during entire program results in Physical Reg File MEM pipeline Rename average 3X slowdown! Rename Reg Addr Update Issue MEM IQ Table Read Calc LSQ Speculation L1 D TLB Manager Load-Store Unit Epoch Deq LSQ (LQ + SQ) Manager Resp Issue Resp Issue Store Scoreboard Ld Ld St St Buffer Front-end L1 D$ 34 Last Level Cache