Enarx allows you to run applications in the public cloud with significantly reduced and better quantifiable risk, specifically guarantees about workload and data confidentiality and integrity. It uses hardware-based security called “Trust Execution Environments” (or TEEs). Enarx allows a tenant to choose a TEE to run their workload without having to re-write the workload for a specific interface. One of the possible choices of TEE to use with Enarx is Intel SGX.
Intel SGX is a process based TEE. It splits the application into an unsecured portion that creates a protected area of execution called an enclave and a secure portion that executes the binary inside an enclave. Any data going in or out of the secure portion is very strictly defined for increased security.
The chip manufacturers have provided a cryptographic mechanism called attestation which enables a host machine to prove to the tenant that it has set up a valid TEE. The first step of attestation is to create a REPORT. This is a measurement of an SGX enclave, obtained by computing a secure hash over the inputs used to create an enclave and load the contents into its memory. A REPORT allows a remote party to verify the source enclave’s identity. Using assembly code to interface with Intel’s instruction set, I generated the REPORT, which will later be used to verify the TEE identity in Enarx’s attestation process. After successfully completing the attestation process, the tenant can now send their workload to the host while making use of the additional security guarantees of the TEE. This code might execute some syscalls. In Intel SGX there is a subset of instructions that can be issued when running a binary inside an enclave. Since syscalls jump to a predefined location setup by the kernel, thereby defeating the purpose of executing inside an enclave, syscalls are illegal instructions. But we still want our clients to be able to make system calls securely, when executing inside an enclave. So what we have done is replace these libc functions with our own implementations. Our intention is to let the developer’s binary make syscalls as if it’s not running on SGX, which allows the developer to use their existing applications in SGX instead of writing a new application for a complex SGX-specific interface.
In addition to generating the REPORT for attestation as described above, I wrote tests that verify if our implementations of system calls work. To reduce code duplication and simplify testing, I devised a tool which only requires a compiled binary as input, it then finds the path to the shim and the loader, executes the binary inside an enclave and validates the results.
Red Hat Intern: Jyotsna Penumaka