It’s been a busy time since we announced Enarx and our vision for running workloads more securely to the world in August 2019. At the time, we had produced a proof of concept demo, creating and attesting a Trusted Execution Environment (TEE) instance using AMD’s Secure Encrypted Virtualization (SEV) capability, encrypting a tiny workload (literally a few instructions of handcrafted assembly language) and sending it to be executed. Beyond that, we had lots of ideas, some thoughts about design, and an ambition to extend the work to other platforms. And since then, a lot has happened, from kicking off the Confidential Computing Consortium to demos with AMD’s SEV and Intel’s Software Guard Extensions (SGX), from contributor improvements to the recent efforts to provide a Wasm module for multiple silicon vendor architectures.
From a project organization point of view, by far the most important event was the donation of Enarx to the Confidential Computing Consortium. Red Hat is a founding member of the Consortium, which was launched under the Linux Foundation in October 2019. It has the aim of promoting use of hardware-based TEEs with open source software. At time of writing, the Consortium has more than thirty-five members. Members range from Arm, Intel, Google, Facebook, Alibaba Cloud and Huawei to start-ups and blockchain companies. From the perspective of the Enarx project, we are particularly pleased that both AMD and Intel are members, as they are the silicon vendors whose TEE implementations (SEV and SGX, respectively) we plan to support initially.
Which brings us to the next piece of news, which is that in October we were able to show another proof of concept demo, this time of a very similar attestation and deployment, but using Intel’s SGX capability. The difference this time was that, because of the underlying libraries we were using within the TEE instance, we didn’t send the entire workload, but only some data. You can find both demos, and instructions for building the SGX demo, over at the Enarx wiki.
Our day-to-day practice in running the project has changed, too. We made a decision very early on that we wanted to be as open as we could possibly be in all aspects of the project. This has, from the beginning, included all the code that we produce, which is in the Enarx Github repository.
The same, of course, goes for documentation. We keep general information in the wiki, design documentation in a documents subrepository, and have a separate repo for RFCs, which can be anything from design discussions through introducing and developing concepts (around trust, for instance) to considerations around what chat systems might best suit our needs. There are only two areas where we may be unable to share everything:
- When some information is made available to members of the project under NDA. This can occur when silicon vendors wish to have conversations about future capabilities in their chips and how they might be affected or used by Enarx, but are not ready to share that information publicly yet.
- If we receive any disclosures relating to security vulnerabilities which need to be embargoed. This is one of the areas that we are currently addressing via our RFC repository, to facilitate a robust and open process.
Keeping all of our documentation and code public isn’t enough, however, if we want to encourage contribution from a wider community across the world. We decided against an email list, and went instead with daily stand-ups over video-conferencing and chat channels. We have regular contributors from central Europe across to the West Coast of the US, and interest from further afield in terms of timezones as well, so finding regular times that suit everybody is hard. We remain committed to supporting those who can’t currently attend our existing live calls, and we’ve found that the chat channels have been very successful in fostering both synchronous and asynchronous collaboration. You can find details about our meetings and chat channels – which are, of course, open to all – in the Enarx wiki.
The most exciting piece of information, however, is very recent, and is a major milestone in the project’s development maturity. As noted above, one of our key design decisions is to support TEEs on multiple silicon vendor architectures: in fact, the goal is to abstract away all of the underlying architecture. Enarx will provide a WebAssembly (Wasm) runtime to allow you to run your workload on whatever platform is available: here is a diagram that we tend to show to illustrate this. (We call the TEE instance, loaded with all the relevant Enarx layers, a “Keep”.)
Sanctum, PEF and MKTME are examples of TEE types which may at some point be sufficiently mature and feature-rich for Enarx support.
The detail is somewhat different for process-based and VM-based TEE types. Here is a slightly different diagram, for SGX specifically:
The equivalent diagram for SEV, a VM-based TEE type, looks like this:
Although the layers look similar across the two architectures, there are actually significant differences in the “Loader” and “Shim” layers, which require very different approaches. A key milestone the Enarx project has been working towards is to build an initial completed version of these layers, to allow us to work on the Wasm and WebAssembly System Interface (WASI) layers above, which are broadly the same across the two architectures.
Our exciting announcement is that we now have working binary applications (ELF static-PIE binary applications, to be specific) that can run on top of both SEV and SGX. Even more exciting is the news that we can execute exactly the same binary on both architectures with no changes and no recompilation. This does not mean that we are ready to run any ELF binary as the Loader and Shim are far from fully-featured, although functional for basic testing. What this does mean, however, is that we are closer to being able to get to our next stage, which is to build out the Wasm and WASI layers, and therefore closer to having a full stack, and the ability to run standard WebAssembly workloads within Keeps.
We are also now in a position where it’s much simpler for external contributors to start looking at, playing with and contributing to the project, which we encourage you to do. We would love to see you in a chat room, at one of our daily meetings, or contributing to the code, documentation or community, so please join us at enarx.io.