Agent Binary
Async Message Manager Secure Message Manager
Scheduler Network Manager
Application
Figure 3.2:Depicts an agent binary that is composed of the application binary and the Diggi library OS. This particular example contains the services compiled for a trusted agent. All components are compiled into asof.
3.3 Agent Communication
Diggi agents communicate with the system, and other agents through an asynchronous lock-free message queue. Diggi’s message manager is versatile and used as a building block to implement more complex features. It implements transparent agent-to-agent communication, either within or between Diggi instances (inter-node). Upon initialization each agent allocates one outbound and one inbound queue. To schedule message between agents, Diggi uses the Global Message Scheduler which is a part of the agent-agent. The message scheduler keeps references to all input/output queue pairs of every agent running on the same Diggi instance. To keep track of the source and destination of a message, the message scheduler uses Diggi’s Agent Identifers (aids).
Therefore, sending a message to an agent only requires the identifier of the recipient agent.
Messages bound for another agent are appended to the queue with a destina-tion identifier. The global message scheduler continuously polls for incoming messages, and copies messages from the outbound queue of the source agent to the inbound queue of the recipient agent. The message manager also transpar-ently implements message passing between Diggi instances with Transmission Control Protocol (tcp). If the message scheduler receives a message with an aidthat is not running on the local Diggi instance, the scheduler maintains a map of agents residing on other instances of Diggi.
24 C H A P T E R3 D I G G I-A F R A M E WO R K F O R T R U S T E D E X E C U T I O N
One of the design principles of Diggi is runtime agnostic agents, allowing agents not running insgxto communicate with those that do. To adhere to that principle, Diggi implements two methods of sending messages: securely, and insecurely. Insecure agents are able to establish atlschannel between agent-agents, or directly targeting a secure agent. Communication between trusted agents are encrypted by default, thus all communication between trusted agents are always subject to encryption. All message queues reside in untrusted memory, because processes outsidesgxare not allowed to access theepc. Therefore, messages that are sent out of the enclave must be copied into unstrusted memory. This scenario is depicted in Figure 3.3.
Secure Agent Secure Agent
Global Message Scheduler
Message Manager Message Manager
OUT IN OUT IN
Figure 3.3:Shows the communication between two agents where the Global message scheduler handles message passing. Both agents run in a enclaves, where messages are subject to encryption. Note that all message queues reside outsideepc.
The message manager is also a building block for asynchronous operations. As Diggi composes an application of smaller logical pieces, agents must have the possibility to issue operations to other agents. Therefore, the message manager supports multiple types of messages: regular message, operations, or system calls. This enables a system agent to receive operations from an application agent asynchronously.
3.4 Summary
This chapter has presented, Diggi, a framework for creating trusted distributed applications, currently utilizing Intel sgx. Specifically, it has described the simple programming abstractions in Diggi, how Diggi splits application into smaller parts in order to reduce the size of trusted components, and how Diggi tackles the performance restrictions of intelsgx.
4
Design & Implementation
This thesis introduces SecureCached, a port of the popular in-memory dis-tributed key-value store Memcached to Diggi. Memcached is an OS-intensive application requiring many features provided by conventional operating sys-tem. Diggi does not yet support the set of features required in order to run legacy applications such as memcached. Therefore, this chapter will first detail the capabilities memcached requires from Linux, followed by the modifica-tions to memcached that are results of Diggi’s architecture. Third, we detail feature extensions to Diggi that emulate a small portion of theposix abstrac-tion. Lastly, we describe how we enabled memcached to run within the Diggi runtime.
Section 4.1 discusses the design choices made when porting memcached to the Diggi runtime, and summarizes the required extensions to Diggi. Section 4.2 gives a brief overview of SecureCached. Section 4.3 explains how we altered Memcached to fit the single-thread Diggi agent programming model.
Section 4.4 and 4.6 describes the implementation of a shim layer to support linux primitives in Diggi. Section 4.8 briefly discusses the implementation of a memcached client supporting a minimal clientapi.
25
26 C H A P T E R4 D E S I G N&I M P L E M E N TAT I O N