Daoli Architecture

The architecture of Daoli intends to put all the work of three universities into one picture, which diagrams building blocks and approaches of trusted grid.

Framework

Overview
According to Daoli meeting and current discussion, we propose a draft for the architecture. It intends to show the work of three universities in one image. There may be problems in it. We can discuss further to make it clear. This architecture combines grid software of HUST, MVMM of Fudan and trusted computing technology of! WuDa? to provide an integral solution to trusted grid. The Fig 1 is drawn according to the Daoli meeting, so it is open to discussion. We hope discuss further to finalize the architecture.

Fig 1 depicts the architecture. HUST implements the grid software both in front end and back end. Technologies of Fudan and WuDa will be used to ensure its security, even when the OS is malicious. The basic elements of the architecture are as follows:
Grid request
Grid request includes user software, data set and policy file. The software is developed by users and performs specific function. It may use additional dataset. Policy file specified the execution environment and security specification. The attestation may depend on the specific policy. The grid software, data set and policy file must be encrypted.
Front End
The front end node of grid is in charge of the resource management and leads the role as resource broker. It consists of trusted VM factory and trusted VM control. Trusted VM factory tries to find suitable image for user software according to the policy. Then it wraps the software and data set using the image, which is deployed in the local or remote node. Trusted VM control is used to start, stop, pause, resume or restart the virtual machine created by grid daemon. The service in the front end node is hosted by CGSP container.
Trusted Image Store
Trusted image store is provided by third party, which stores thousands of images. Each image is an execution environment for the user software, which can be launched as a virtual machine. The image can be customized by grid user themselves.
Back End Node
The software of grid users will run in the back end nodes. Every back end node supports Xen virtual machine monitor provided by Fudan University. The Grid daemon, Migration daemon and TCS run as processes in the domain 0, which has privileged rights. They are all protected by memory curtain techniques.
Grid Daemon
The grid daemon is provided by HUST, which communicates with front end node to perform grid related tasks including deployment of virtual machine, control of virtual machine and so on. It provides standard service interface and can be called by any front end node according to the standard protocol. The programs submitted by grid users must be encrypted before wrapping. The encryption standard is provided by Fudan University.
Migration Daemon
Similar to grid daemon, Migration daemon also runs in domain 0. It is in charge of the credential and user task migration. It also does some work about attestation.
TCS
The TCS is provided by Wuhan University, which belongs to standard trusted software stack supporting hardware TPM. Applications communicate with TCS to use hardware TPM (or TCM).
TPM (or TCM) Manager
The TPM (or TCM) manager is hosted in the Xen virtual machine monitor, which intends to provide concurrency control. It may also include vTPM, which is under discussion. According to Wuhan University, TPM (or TCM) manager must differentiate the call from trusted process or normal process. The function about TPM (or TCM) is provided directly by Xen, which interpolates the related system call by applications, performs it and don't forward it to OS. All the TPM (or TCM) calls don't pass through OS.
VMM and OS
The VMM and OS are provided by Fudan University, which ensures the security of trusted process even when the OS is malicious. They are the basic platform for Daoli. Fudan University claims that:
(1) The program for trusted process must be static linked.
(2) The OS supports all the system API and make sure that the semantic doesn't change. All the inter-process communication interfaces are supported. Trusted process and other processes can communicate by shared memory.
(3) Xen provides all the TPM (or TCM) related function.
(4) Xen need support dynamic virtual machine launch, migration and VTPM. It is open to discussion.

Trusted Grub
Wuhan University measures virtual machine monitor by Trusted Grub. A bin program is inserted between BIOS and Trusted Grub, which is used to unbind trusted grub and protect it. Currently there are no good solutions to protect the bin programs.

vTPM daemon
vTPM daemon is TPM backend driver which implements virtual separate TPM (or TCM) instance for every virtual machine. It calls TCS to use hardware TPM.

Remote Deploy Service
Remote Deploy service is a daemon included in every image. When trusted VM factory deploy image as a virtual machine, it starts running. Grid daemon will retrieve programs and data file from user request, do encryption, call remote deploy service to place them in the virtual machine and start it. The remote deploy service and user applications are all protected by memory curtaining.

Mechanism

• Deploy image and start user programs

We must add a daemon process to OS when making images. The process, which is called remote deploy service, is listening on some port when started. Grid daemon in domain 0 connects to the service and sent it the user programs and data file. The remote deploy service encrypts the programs received according to standard provided by Fudan University and launch it as a trusted process. The key point is that grid daemon launches the virtual machine first, deploys the user software and then starts it.

• Make images and launch it

Need refinement.

• Measure VMM and Image

VMM is measured by Trusted Grub. Every image in the trusted image store will be measured and has a hash value. When front end node finds a suitable image, grid daemon will download it from image store and try to launch it as a virtual machine. At this time, the image will be measured again and compared to the hash value in the image store.

• vTPM

It is now under discussion. vTPM is an implementation as split driver model. vTPM is a application process in domain 0, which is called vTPM daemon. It maintains one TPM (or TCM) instance for every virtual machine and calls TCS to use hardware TPM (or TCM). Applications in other domain contact vTPM daemon to use virtual TPM (or TCM). HUST prepared for adopting the framework developed by IBM. The key point of vTPM is that every virtual machine has an independent TPM.

• How Xen expose hardware TPM to TCS

All the function about TPM (or TCM) is hosted in Xen. When TCS tries to use hardware TPM (or TCM), it must call the ordinary file API. These calls are intercepted by Xen. Xen performs the corresponding function and return the result to applications. OS is unaware of these calls. It is current solution of Fudan.

• Concurrency control of TPM (or TCM)

Wuhan University suggests implement concurrency control in Xen layer, which intends to serialize the TPM (or TCM) commands and differentiate the call between trusted processes and un-trusted processes. Fudan University thinks that it is not necessary.It is open to discussion.

• Migration

HUST plans to migrate a virtual machine by snapshot. Xen of Fudan currently doesn't support snapshot. So we need migrate the user software and related mediate state. We suggest attach every programs a data file to store the input, output and states. Xen must support virtual machine migration. Virtual machine migration is open to discussion.

• Distribution of Trusted Image Store

There exists performance issue on image deployment. The images are always too large to download it from a remote server. So at least the image store must be distributed rather than central. It is even too slow to retrieve image from a server on LAN and deploy it.

• How user submit programs

This topic is open to discussion. The programs submitted by user are source files or executable files? If they are executable, how does user specify its execution environment? How do users compile the source files? If the source files are compiled, how can broker find the suitable execution environment for them?

• How grid ensure users' arbitrary policy

This topic is open to discussion. The users can specify any policy. How does the grid perform policy enforcement?

Secure Migration

--> More info about Solution to secure migration

Attestation model and protocol

--> More info about Attestation model and protocol

Comments