Asylo 0.4.0 Release

[Asylo Users]

We’re excited to announce the 0.4.0 release of Asylo. This release marks a significant milestone in functionality and ease-of-use.

Running existing applications in enclaves

In the 0.3.4 release, we introduced the “cc_enclave_binary” Bazel macro, which enables running an entire application (written without enclaves or Asylo in mind) inside an enclave without modifying its source code.

Initially, “cc_enclave_binary” worked only with simulated enclaves. We’ve now enhanced that support to work with hardware SGX enclaves and published an example guide for running the popular Redis key-value database in an Asylo enclave. This application was chosen because it required solving some really interesting technical problems.

Foremost among these challenges was Redis’s reliance on fork() for snapshotting/saving state. Enclave technologies like SGX are specifically designed to prevent leaking or copying of program state, but fork() is all about cloning process state. Asylo now allows a fork() initiated from within the enclave by securely transferring enclave state to an identical enclave. The fork() call has to be initiated by the enclave being forked, and it results in at most one cloned enclave per call.

We will soon be publishing a blog post about this approach and the technical challenges entailed.

Thread mapping changes

In this release, we are also changing the way untrusted threads outside the enclave are mapped to trusted threads inside the enclave when using SGX enclaves. This may impact some user applications, so we’d like to summarize what we’ve done and why this change is required.

The Intel SGX SDK supports two different policies for binding threads to TCS slots, controlled by the configuration parameter TCS_POLICY (configurable in Asylo with the tcs_policy field of sgx_enclave_configuration in your BUILD file).

• With TCS_POLICY=0, an untrusted thread is bound to a TCS the first time it enters the enclave, and that binding is persisted for the lifetime of the enclave. An untrusted thread may only enter on the TCS it is bound to. Thread-local variables are preserved across calls to the enclave.
• With TCS_POLICY=1, an untrusted thread is not bound to a TCS slot. An untrusted thread may enter on any available TCS. All thread local variables are reinitialized to zero each time a thread enters the enclave.

Previously, with Asylo defaulting to TCS_POLICY=1, some users were seeing problems related to the treatment of thread local storage. In this mode, thread local storage is reinitialized periodically in ways that existing C++ code does not anticipate, which causes problems when trying to support some external libraries like absl::Mutex inside the enclave.

To address these issues, we have switched over to a default of TCS_POLICY=0. However, this changes the behavior of existing Asylo client code. Previously, user code could enter the enclave on more untrusted threads than the number of TCS slots in the enclave, and each thread would be dynamically assigned resources at thread entry. With the new default setting, untrusted code inside the Intel SDK will maintain a mapping from thread to TCS slot. This means that it is no longer possible to enter the enclave from a pool of threads larger than the configured number of TCS slots. It is possible to continue using the previous behavior by creating an sgx_enclave_configuration with tcs_policy set to 1. However, in doing so, users may reintroduce a memory leak related to Asylo’s internal use of thread-local storage.

Change Summary

As always, there are also a large number of behind-the-scenes improvements and work toward future functionality.

The changes since 0.3.4 include:

• Changed default TCS_POLICY
• Added guide for wrapping entire applications in an enclave
• Added secure handling of data in fork() implementation
• Significant progress toward fully using our new “primitives” backend abstraction layer
• Significant progress toward supporting SGX platform provisioning and remote attestation
• Deprecated asylo_proto_library and asylo_grpc_proto_library Bazel macros
• Additional POSIX interface implementations
• Updated to newer versions of primary dependencies
• Improved documentation and testing
• Maintenance work and bug fixes

The release can be found on GitHub at https://github.com/google/asylo/releases/tag/v0.4.0. You can join the discussion on the asylo-users mailing list with feedback and questions for the community.