E Actors: an actor-based programming framework for Intel SGX Dr.-Eng. V. A. Sartakov 01.02.2x20 Imperial College London
Plan Why do we need another framework? The framework Fundamentals Messaging System Components Benchmark Examples Future plans Conclusion 1
New System Component for Trusted Execution • Special features: remote/local Enc. 1 Enc. 2 App Kernel Hypervisor attestation, data sealing Base (TCB) Software Guard eXtensions (SGX) from the Trusted Computing • Remove an OS and a hypervisor reset [2] and DMA attacks [3] • Protect cold-boot [1], platform untrusted environment: enclaves enable trusted execution in 2
Intel SGX Software Development Kit Programming approach: • Invocation of functions Advantages: • Low TCB • Intuitive use Disadvantages: • Infmexible partitioning • High transition costs • ECALL, OCALL: 50 • sgx_mutex: 200 Untrusted 3
Intel SGX Software Development Kit gate Enclave Untrusted OCALL bar( ) gate call bar( ) ECALL foo( ) call foo( ) Programming approach: • High transition costs • Infmexible partitioning Disadvantages: • Intuitive use • Low TCB Advantages: • Invocation of functions 3 • ECALL, OCALL: ≈ 50 × • sgx_mutex: ≈ 200 ×
Existing Approaches::LibOS/Shim Layer Programming approach: • Enclave the whole application Frameworks: • Haven [4], SCONE [5], Graphene-SGX [6], Panoply [7] Advantages: • Legacy • Fast transitions (some) Disadvantage: • Monolithic design Large TCB Untrusted Library OS/shim Application 4
Existing Approaches::LibOS/Shim Layer Programming approach: • Enclave the whole application Frameworks: • Haven [4], SCONE [5], Graphene-SGX [6], Panoply [7] Advantages: • Legacy • Fast transitions (some) Disadvantage: Untrusted Library OS/shim Application 4 • Monolithic design → Large TCB
Towards Multi-enclave Applications C4 Secure multi-party computation C1 C3 C2 Enclave #3 Enclave #2 Enclave #1 Partitioned instant message service C1 C2 C3 Enclave #2 A single process can host Enclave #1 • Flexible partitioning • Minimal per-enclave TCB communication • Fast enclave-to-enclave Programming model should ofger: • Secure-multiparty computation • Instant message service Examples: multiple enclaves 5 → Mutually distrusted partitions
Towards Actors-Based Trusted Computing (CAF) A#5 A#2 A#1 A#4 A#3 Need another framework • Do not tailored for enclaves Actors: • Heavy runtime (Erlang, Java) Existing frameworks: • Use messages • Non-blocking 6 → Shared-nothing (no locks!) → Lightweight (fmexible!)
Towards Actors-Based Trusted Computing (CAF) A#5 A#2 A#1 A#4 A#3 • Do not tailored for enclaves Actors: • Heavy runtime (Erlang, Java) Existing frameworks: • Use messages • Non-blocking 6 → Shared-nothing (no locks!) → Lightweight (fmexible!) → Need another framework
Plan Why do we need another framework? The framework Fundamentals Messaging System Components Benchmark Examples Future plans Conclusion 7
E Actors: Actors-based Trusted Computing • What is an Actor ? • How actors communicate? • System support A#3 A#4 A#1 A#2 A#5 8
General View • workers to CPUs PONG Components: A 2 A 1 PING Bindings: • Workers • Enclaves 9 Enclave # 1 Enclave # 2 • e actor s CPU # 0 Worker # 1 CPU # 1 Worker # 2 CPU # 2 • e actor s to enclaves • e actor s to workers Worker # 3 CPU # 3
10 >channel [ 1 ] , 7 ^^ I /∗ r e c e i v e a pong ∗/ 8 >channel [ 0 ] ) ; 9 i f (msg == NULL) 10 return ; 11 } 12 /∗ send a ping ∗/ 13 ” ping ” ) ; >f i r s t = 0; 14 } 15 16 void aping_ctr ( struct actor ∗ s e l f ) { 17 >f i r s t = 1; 18 >channel [ 0 ] ) ; 19 } 6 } else { struct 2 • Enclave’s binaries • Untrusted binaries 1 XML state { struct • Deployment channel chan [ 2 ] ; int f i r s t ;} 3 • Framework void aping ( struct actor ∗ s e l f ) { 4 Building: • Private state • Body function >f i r s t ) { 5 • Constructor Output: Programming with e actor s An e actor : i f ( s e l f − >state − s e l f − >state − char ∗ msg = recv(&s e l f − • e actor ’s source send(&s e l f − s e l f − >state − connect ( s e l f −
Nodes – a Basis for Messaging Payload Header NULL *prev Payload *top lock *bottom Header *next NULL tail/front The node is a memory object: • push_to/pop_from exchange • mbox : FIFO for message nodes • pool : LIFO for empty API: • Double-linked queues • Private or public • Allocated at startup • Header, Payload 11
Nodes – a Basis for Messaging Payload Header NULL *prev Payload *top lock *bottom Header *next NULL tail/front The node is a memory object: • push_to/pop_from exchange • mbox : FIFO for message nodes • pool : LIFO for empty API: • Double-linked queues • Private or public • Allocated at startup • Header, Payload 11
Message-based Communication Send/receive: 1. PING : Dequeue a node 2. PING : Write (enc.) data 3. PING : Enqueue to a mbox 4. PONG : Dequeue from mbox 5. PONG : Read (dec.) data 6. PONG : Return the node mbox POOL Enclave #1 Enclave #2 PING PONG 12
Message-based Communication Send/receive: 1. PING : Dequeue a node 2. PING : Write (enc.) data 3. PING : Enqueue to a mbox 4. PONG : Dequeue from mbox 5. PONG : Read (dec.) data 6. PONG : Return the node mbox POOL Enclave #1 Enclave #2 PING PONG 12
Message-based Communication mbox PONG PING Enclave #2 Enclave #1 POOL %$ 6. PONG : Return the node Send/receive: 5. PONG : Read (dec.) data mbox 4. PONG : Dequeue from 3. PING : Enqueue to a mbox 2. PING : Write (enc.) data 1. PING : Dequeue a node 12
Message-based Communication mbox PONG PING Enclave #2 Enclave #1 POOL %$ 6. PONG : Return the node Send/receive: 5. PONG : Read (dec.) data mbox 4. PONG : Dequeue from 3. PING : Enqueue to a mbox 2. PING : Write (enc.) data 1. PING : Dequeue a node 12
Message-based Communication mbox PONG PING Enclave #2 Enclave #1 POOL %$ 6. PONG : Return the node Send/receive: 5. PONG : Read (dec.) data mbox 4. PONG : Dequeue from 3. PING : Enqueue to a mbox 2. PING : Write (enc.) data 1. PING : Dequeue a node 12
Message-based Communication mbox PONG PING Enclave #2 Enclave #1 POOL %$ 6. PONG : Return the node Send/receive: 5. PONG : Read (dec.) data mbox 4. PONG : Dequeue from 3. PING : Enqueue to a mbox 2. PING : Write (enc.) data 1. PING : Dequeue a node 12
Message-based Communication Send/receive: 1. PING : Dequeue a node 2. PING : Write (enc.) data 3. PING : Enqueue to a mbox 4. PONG : Dequeue from mbox 5. PONG : Read (dec.) data 6. PONG : Return the node mbox POOL Enclave #1 Enclave #2 PING PONG 12
Connectors and Cargos Nodes and queues are low-level communication primitives Cargos and Connectors are high-level communication primitives • Unifjed interfaces for encrypted and non-encrypted messages • Based on nodes and queues • P2P message exchange • Uses local-attestation for the key-exchange procedure 13 + Multi-Producer Multi-Consumer − Plain text
Connectors and Cargos Nodes and queues are low-level communication primitives Cargos and Connectors are high-level communication primitives • Unifjed interfaces for encrypted and non-encrypted messages • Based on nodes and queues • P2P message exchange • Uses local-attestation for the key-exchange procedure 13 + Multi-Producer Multi-Consumer − Plain text
System Components::System Actors and EOS System actors: • Message based interaction TCP/IP stack READER/WRITER OPENER CLOSER Enclave #1 A1 Enclave #2 A2 14 • e actor cannot use syscalls • Multiple system e actor s
System Components::System Actors and EOS non-encrypted 0x7fgb00000000 +size 0 KVP#2 0 KVP#1 POOL B32 ... B1 Grace counters Sealed keys Super block • Persistence on demand • Can be encrypted or System actors: • Can be private or public • Key-value store E actors Object Store: A2 Enclave #2 A1 Enclave #1 CLOSER OPENER READER/WRITER TCP/IP stack • Message based interaction 14 • e actor cannot use syscalls • Multiple system e actor s
Ping-pong Ping-pong: PONG PING mbuf mbuf PONG PING • 2 Actors, cargos E Actors: ECALLs • 2 threads, SDK: • 16–512 KiB messages • 1,000,000 15 MB # 1 MB # 2
Ping-pong 256K Encrypted E Actors SDK 0 SDK: 319 (1783 512K Encrypted: 974 E Actors: 9706 cache • 32KiB – L1 peak) 16 10 , 000 Throughput ( MiB / s ) 5 , 000 16 64K128K Message size ( Bytes )
Ping-pong 256K Encrypted E Actors SDK 0 SDK: 319 (1783 512K Encrypted: 974 E Actors: 9706 cache • 32KiB – L1 peak) 16 10 , 000 Throughput ( MiB / s ) 5 , 000 16 64K128K Message size ( Bytes )
Ping-pong 512K Encrypted E Actors SDK SDK: 319 (1783 0 16 256K Encrypted: 974 E Actors: 9706 cache • 32KiB – L1 peak) 10 , 000 10 × Throughput ( MiB / s ) 30 × 2.9 × 5 , 000 16 64K128K Message size ( Bytes )
Recommend
More recommend
