E Actors: an actor-based programming framework for Intel SGX - - PowerPoint PPT Presentation

e actors an actor based programming framework for intel
SMART_READER_LITE
LIVE PREVIEW

E Actors: an actor-based programming framework for Intel SGX - - PowerPoint PPT Presentation

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


slide-1
SLIDE 1

EActors: an actor-based programming framework for Intel SGX

Dr.-Eng. V. A. Sartakov 01.02.2x20

Imperial College London

slide-2
SLIDE 2

Plan

Why do we need another framework? The framework Fundamentals Messaging System Components Benchmark Examples Future plans Conclusion

1

slide-3
SLIDE 3

New System Component for Trusted Execution

Software Guard eXtensions (SGX) enclaves enable trusted execution in untrusted environment:

  • Protect cold-boot [1], platform

reset [2] and DMA attacks [3]

  • Remove an OS and a hypervisor

from the Trusted Computing Base (TCB)

  • Special features: remote/local

attestation, data sealing

Hypervisor Kernel App

  • Enc. 2
  • Enc. 1

2

slide-4
SLIDE 4

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

slide-5
SLIDE 5

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×

call foo( ) gate foo( )

ECALL

call bar( ) gate bar( )

OCALL

Untrusted Enclave

3

slide-6
SLIDE 6

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

slide-7
SLIDE 7

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

slide-8
SLIDE 8

Towards Multi-enclave Applications

A single process can host multiple enclaves → Mutually distrusted partitions Examples:

  • Instant message service
  • Secure-multiparty computation

Programming model should ofger:

  • Fast enclave-to-enclave

communication

  • Minimal per-enclave TCB
  • Flexible partitioning

Enclave #1 Enclave #2 C4 C3 C2 C1

Partitioned instant message service

Enclave #1 Enclave #2 Enclave #3 C2 C3 C1

Secure multi-party computation

5

slide-9
SLIDE 9

Towards Actors-Based Trusted Computing

Actors:

  • Non-blocking
  • Use messages

→ Shared-nothing (no locks!) → Lightweight (fmexible!) Existing frameworks:

  • Heavy runtime (Erlang, Java)
  • Do not tailored for enclaves

(CAF) Need another framework

A#3 A#4 A#1 A#2 A#5

6

slide-10
SLIDE 10

Towards Actors-Based Trusted Computing

Actors:

  • Non-blocking
  • Use messages

→ Shared-nothing (no locks!) → Lightweight (fmexible!) Existing frameworks:

  • Heavy runtime (Erlang, Java)
  • Do not tailored for enclaves

(CAF) → Need another framework

A#3 A#4 A#1 A#2 A#5

6

slide-11
SLIDE 11

Plan

Why do we need another framework? The framework Fundamentals Messaging System Components Benchmark Examples Future plans Conclusion

7

slide-12
SLIDE 12

EActors: Actors-based Trusted Computing

  • What is an Actor?
  • How actors communicate?
  • System support

A#3 A#4 A#1 A#2 A#5

8

slide-13
SLIDE 13

General View

Components:

  • eactors
  • Enclaves
  • Workers

Bindings:

  • eactors to enclaves
  • eactors to workers
  • workers to CPUs

A1 A2 PING PONG CPU#1 CPU#0 CPU#2 CPU#3 Enclave #2 Enclave #1

Worker #1 Worker #2 Worker #3 9

slide-14
SLIDE 14

Programming with eactors

An eactor:

  • Constructor
  • Body function
  • Private state

Building:

  • eactor’s source
  • Deployment

XML

  • Framework

Output:

  • Enclave’s

binaries

  • Untrusted

binaries

1

struct state { struct channel chan [ 2 ] ; int f i r s t ;}

2 3

void aping ( struct actor ∗ s e l f ) {

4

i f ( s e l f − >state− >f i r s t ) {

5

s e l f − >state− >f i r s t = 0;

6

} else {

7

^^ I /∗ r e c e i v e a pong ∗/

8

char∗ msg = recv(&s e l f − >channel [ 0 ] ) ;

9

i f (msg == NULL)

10

return ;

11

}

12

/∗ send a ping ∗/

13

send(&s e l f − >channel [ 1 ] , ” ping ” ) ;

14

}

15 16

void aping_ctr ( struct actor ∗ s e l f ) {

17

s e l f − >state− >f i r s t = 1;

18

connect ( s e l f − >channel [ 0 ] ) ;

19

} 10

slide-15
SLIDE 15

Nodes – a Basis for Messaging

The node is a memory object:

  • Header, Payload
  • Allocated at startup
  • Private or public
  • Double-linked queues

API:

  • pool: LIFO for empty

nodes

  • mbox: FIFO for message

exchange

  • push_to/pop_from

tail/front

Payload NULL *next Header *bottom lock *top Payload *prev NULL Header 11

slide-16
SLIDE 16

Nodes – a Basis for Messaging

The node is a memory object:

  • Header, Payload
  • Allocated at startup
  • Private or public
  • Double-linked queues

API:

  • pool: LIFO for empty

nodes

  • mbox: FIFO for message

exchange

  • push_to/pop_from

tail/front

Payload NULL *next Header *bottom lock *top Payload *prev NULL Header 11

slide-17
SLIDE 17

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

slide-18
SLIDE 18

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

slide-19
SLIDE 19

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

slide-20
SLIDE 20

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

slide-21
SLIDE 21

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

slide-22
SLIDE 22

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

slide-23
SLIDE 23

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

slide-24
SLIDE 24

Connectors and Cargos

Nodes and queues are low-level communication primitives + Multi-Producer Multi-Consumer − Plain text 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

slide-25
SLIDE 25

Connectors and Cargos

Nodes and queues are low-level communication primitives + Multi-Producer Multi-Consumer − Plain text 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

slide-26
SLIDE 26

System Components::System Actors and EOS

System actors:

  • eactor cannot use syscalls
  • Multiple system eactors
  • Message based interaction

TCP/IP stack READER/WRITER OPENER CLOSER Enclave #1 A1 Enclave #2 A2

14

slide-27
SLIDE 27

System Components::System Actors and EOS

System actors:

  • eactor cannot use syscalls
  • Multiple system eactors
  • Message based interaction

TCP/IP stack READER/WRITER OPENER CLOSER Enclave #1 A1 Enclave #2 A2

Eactors Object Store:

  • Key-value store
  • Can be private or public
  • Can be encrypted or

non-encrypted

  • Persistence on demand

Super block Sealed keys Grace counters B1 ... B32 POOL KVP#1 KVP#2

+size 0x7fgb00000000

14

slide-28
SLIDE 28

Ping-pong

Ping-pong:

  • 1,000,000

messages

  • 16–512 KiB

SDK:

  • 2 threads,

ECALLs EActors:

  • 2 Actors, cargos

PING PONG

mbuf mbuf

PING PONG

MB#1 MB#2

15

slide-29
SLIDE 29

Ping-pong

SDK: 319 (1783 peak)

  • 32KiB – L1

cache EActors: 9706 Encrypted: 974 16 64K128K 256K 512K 5,000 10,000 Message size (Bytes) Throughput (MiB/s) SDK EActors Encrypted

16

slide-30
SLIDE 30

Ping-pong

SDK: 319 (1783 peak)

  • 32KiB – L1

cache EActors: 9706 Encrypted: 974 16 64K128K 256K 512K 5,000 10,000 Message size (Bytes) Throughput (MiB/s) SDK EActors Encrypted

16

slide-31
SLIDE 31

Ping-pong

SDK: 319 (1783 peak)

  • 32KiB – L1

cache EActors: 9706 Encrypted: 974 16 64K128K 256K 512K 5,000 10,000

2.9× 30× 10×

Message size (Bytes) Throughput (MiB/s) SDK EActors Encrypted

16

slide-32
SLIDE 32

Some Examples and Demos

Sources: https://github.com/ibr-ds/EActors/tree/master/examples template Simple hello-world actor pingpong non-encrypted messages pingpong2 cargo-based messaging pingpongLA Local attestation smc Secure multi-party computation eos EActors object store http A simple web server with SSL https://primate.ibr.cs.tu-bs.de

17

slide-33
SLIDE 33

Plan

Why do we need another framework? The framework Fundamentals Messaging System Components Benchmark Examples Future plans Conclusion

18

slide-34
SLIDE 34

EActors:: What is next?

  • Hardening – Isolation for actors
  • Auto partitioning
  • Multi-enclave Applications
  • Independent from Intel SGX SDK

19

slide-35
SLIDE 35

Plan

Why do we need another framework? The framework Fundamentals Messaging System Components Benchmark Examples Future plans Conclusion

20

slide-36
SLIDE 36

Takeaway

  • EActors – an actor-based programming framework
  • C, uses the Intel SGX SDK
  • Targets multi-enclave use cases
  • Provides system components
  • High-performance communication primitives

Sources: https://github.com/ibr-ds/EActors Thank you!

21

slide-37
SLIDE 37

References i

  • J. A. Halderman, S. D. Schoen, N. Heninger, W. Clarkson, W. Paul,
  • J. A. Calandrino, A. J. Feldman, J. Appelbaum, and E. W. Felten,

“Lest we remember: cold-boot attacks on encryption keys,” Communications of the ACM, vol. 52, no. 5, pp. 91–98, 2009.

  • A. Boileau, “Hit by a bus: Physical access attacks with fjrewire,”

Presentation, Ruxcon, vol. 3, 2006.

  • B. Böck and S. B. Austria, “Firewire-based physical security attacks
  • n windows 7, efs and bitlocker,” Secure Business Austria Research

Lab, 2009.

  • A. Baumann, M. Peinado, and G. Hunt, “Shielding applications from

an untrusted cloud with haven,” ACM Transactions on Computer Systems (TOCS), vol. 33, no. 3, p. 8, 2015.

slide-38
SLIDE 38

References ii

  • S. Arnautov, B. Trach, F. Gregor, T. Knauth, A. Martin, C. Priebe,
  • J. Lind, D. Muthukumaran, D. O’Keefge, M. Stillwell et al., “SCONE:

Secure Linux Containers with Intel SGX.” in OSDI, 2016, pp. 689–703.

  • C. Tsai, D. E. Porter, and M. Vij, “Graphene-SGX: A Practical

Library OS for Unmodifjed Applications on SGX,” in 2017 USENIX Annual Technical Conference (USENIX ATC 17), 2017, pp. 645–658.

  • S. Shinde, D. Le Tien, S. Tople, and P. Saxena, “PANOPLY:

Low-TCB Linux Applications With SGX Enclaves,” in Proc. of the Annual Network and Distributed System Security Symp.(NDSS), 2017.