Run Rust SGX Applications in Mesalock Linux
MesaLock Linux is a general purpose Linux distribution which aims to provide a safe and secure user space environment. To eliminate high-severe vulnerabilities caused by memory corruption, the whole user space applications are rewritten in memory-safe programming languages like Rust and Go. This extremely reduces attack surfaces of an operating system exposed in the wild, leaving the remaining attack surfaces auditable and restricted. Therefore, MesaLock Linux can substantially improve the security of the Linux ecosystem. Additionally, thanks to the Linux kernel, MesaLock Linux supports a broad hardware environment, making it deployable in many places. Two main usage scenarios of MesaLock Linux are for containers and security-sensitive embedded devices. With the growth of the ecosystem, MesaLock Linux would also be adopted in the server environment in the future.
We believe that running Rust SGX applications inside Mesalock Linux could improve the security of SGX applications and reduce their attack surface significantly.
Is it safe to run Rust SGX applications in Mesalock Linux?
A typical Rust SGX application has at least to components: one enclave, and one untrusted component. The enclave is self-contained and doesn't need dynamic loading. The untrusted component depends on
liburts (untrusted runtime service library), which depends on the Application Enclave Services Manager library.
We show the dependency tree as follows. In this tree, we hide all the dynamic libraries which already exist in Mesalock Linux.
SGX Application ├── Enclave (statically linked) └── Untrusted component └── SGX untrusted runtime (libsgx_urts.so) ├── libstdc++ (libstdc++.so.6) └── AESM service library (libsgx_uae_service.so) └── libprotobuf (libprotobuf.so.9) ├── libstdc++ (libstdc++.so.6) └── zlib (libz.so.1)
We can see that, to support Rust SGX applications in Mesalock Linux, the minimum set of required shared library is : libsgx_urts.so, libsgx_uae_service.so, libstdc++.so.6, libz.so.1 and libprotobuf.so.9.
We refined the rules-of-thumb for hybrid memory-safe architecture designing and here is the refined version.
- Unsafe components must not taint safe components, especially for public APIs and data structures.
- Unsafe components should be as small as possible and decoupled from safe components.
- Unsafe components should be explicitly marked during deployment and ready to upgrade.
Hence, we believe that running Rust SGX applications in Mesalock Linux could provide better security guarantees if they follow the memory safety principles.
The whole solution contains two steps:
- Build Rust SGX applications in dev environment, such as Rust SGX docker container.
- Run Rust SGX application in Mesalock Linux docker container.
Step 1 is trivial.
For step 2, the Intel AESM service is required. Technically, Intel AESM service listens at a domain socket
/var/run/aesmd/aesm.socket and provide service via this domain socket. To interact with CPU, Intel AESM service needs to access
There are two options for running the aesm service: (1) start
aesmd inside the Mesalock Linux container, or (2) start
aesmd on the host OS and provide service to the SGX application inside the container. The first method provides better isolation for
aesmd, but it would start a set of infrastructure enclaves for each docker container, wasting the limited EPC memory. The second one only launches one set of infrastructure enclaves for all SGX containers and we believe it is more efficient.
In our current solution, we put the AESM service process
aesmd outside the Mesalock Linux docker container and only expose the domain socket
/var/run/aesm/aesm.socket to the container. In this way, we isolate the AESM service along with the six foundation enclaves (Launch Enclave/Quoting Enclave/Provisioning Enclave/Provisioning Certification Enclave/Platform Service Enclave for long term pairing/Platform Service Enclave for session management) from Mesalock Linux docker container.
Rust SGX SDK and docker
Step 1 : build SGX application in Rust SGX dev docker container.
$ git pull firstname.lastname@example.org:baidu/rust-sgx-sdk.git $ docker run -v /path/to/rust-sgx-sdk:/root/sgx -ti --device /dev/isgx baiduxlab/sgx-rust
In the Rust SGX dev docker container:
$ cd /root/sgx/samplecode/hello-rust $ make ...(ignored many lines)... </EnclaveConfiguration> tcs_num 1, tcs_max_num 1, tcs_min_pool 1 The required memory is 1732608B. Succeed. SIGN => bin/enclave.signed.so $ exit
hello-rust sample has been compiled successfully.
Step 2 : run SGX application in Mesalock Linux docker container
$ docker run --rm -ti \ --device /dev/isgx \ # forward isgx device -v /path/to/rust-sgx-sdk:/root/sgx \ # add SDK -v /path/to/rust-sgx-sdk/mesalock-rt:/opt/sgxrt \ # add runtime lib -v /var/run/aesmd:/var/run/aesmd \ # forward domain socket -e LD_LIBRARY_PATH=/opt/sgxrt \ # set lib path -w /root/sgx/samplecode/hello-rust/bin \ # set working dir mesalocklinux/mesalock-linux
Now the Mesalock Linux docker container has been initiated using method (2) and an Ion shell has been launched. In the container, we execute:
:/root/sgx/samplecode/hello-rust/bin$ ./app [+] Home dir is /root [-] Open token file /root/enclave.token error! Will create one. [+] Saved updated launch token! [+] Init Enclave Successful 2! This is a normal world string passed into Enclave! This is a in-Enclave Rust string! [+] say_something success...
mesalock-rt Runtime Details
All these runtime shared libraries come from official releases, including Intel SGX SDK v2.0 release and Ubuntu 16.04 package archive.