Before the advent of cloud based computing and public cloud services like Google Cloud and AWS, a user’s program and data would be stored locally on their own device. The only protection needed was to build protections against external intrusions. However, with the shift towards cloud, a user’s data is now sitting on commodity OS and hardware. Furthermore, the inherently hierarchical nature of cloud infrastructure doesn’t provide any protections for user data from privileged code access. A malicious cloud provider would still be able to observe and modify data even if it’s encrypted. The TCB as it currently stands is quite extensive (privileged software, staff, management stack, legal). Existing solutions such as hardware security modules, remote attestation, or trusted hypervisors suffer from being too expensive, limit in capability, or an unavoidable trust in the provider. All these approaches fail to protect a program from the rest of the system. The goal of this paper is to provide shielded execution to protect programs’ confidentiality and integrity as a general solution for allowing cloud computing users to trust service providers. In other words, even when faced with a malicious cloud provider, a user should be able to execute a program without exposing any information or endangering the program’s integrity.

The core techniques of this paper involve using hardware provided instructions, defined by Intel SGX, to enable the creation of protected memory regions, also called enclaves, which serve as “safe havens” for an application’s execution code to be run. Haven establishes an assumption where the OS and application do not trust one another, which is why syscalls cannot be directly communicated to and executed by the host OS kernel. The Intel SGX serves as the bridge that allows the program to solicit services from the host OS despite the mutual distrust. From an architectural standpoint, the user's binaries are stored in the enclave, in addition to LibOS and a shield module that provides abstractions for threads, scheduling, file system, virtual memory, etc.

I found the motivation, solution description, and implementation of Haven all to be well defended and aptly quantified. However, while understandable, I felt like the performance results were not very definitive primarily because of the lack of an implementation for SGX at the time of the paper. The attempt at modeling SGX induced overhead gives us some semi-tangible insight into the cost of introducing such a system. In short, the overhead is quite significant. RAM is assumed to be 30% slower and SGX instructions have inflated to around 10k cycles. Out of the popular commodity software they tested, Apache (35%) and the SQL Server (65%) suffered pretty significant slowdowns which may not be tolerable to users. Put simply, the performance hit from enforcing privacy is non-negligible.

I think this paper was an excellent case study of a potential application of SGX, demonstrating how for certain security applications and contexts, a CPU that can be trusted means tremendous performance gains. The authors discuss their own visions in section 7.2 (Future Work). Out of the three, I thought Cloud Management carried the most exciting potential for further use of enclaves. The untrusted time problem seems like it has a solution in finding a trusted third-party entity to cross check against the host system time. I found the storage rollback problem to be most interesting. The presented solution on communicating on critical writes to limit the network cost by limiting the number of writes seems pretty limiting. I think it opens up interesting questions in the DBMS department on potential usage of enclaves. Among several publications on applying SGX to system privacy, I very much enjoyed this paper's clarity.