\HeadingLevelA{Conclusion}
\label{sec:conclusion}

This manuscript is the second of a two-part review of secure processor systems that aims to enable remote computation with guarantees of privacy and integrity. Part I of this survey established the background, taxonomy, and prior work relevant for a discussion of trusted remote computation. Part I also described the secure isolation container (enclave), as exemplified by Intel's Secure Guard Extensions (SGX), as an effective primitive for secure remote computation. This manuscript, Part II, relies on the fundamentals discussed previously and extends the discussion of enclaves with an in-depth investigation of the implementation, security-critical mechanisms, threat model, and shortcomings of SGX.

Shortly after we learned about Intel's Software Guard Extensions (SGX) initiative, we set out to study it in the hope of finding a practical solution to its vulnerability to cache timing attacks. After reading the official SGX manuals, we were left with more questions than when we started. The SGX patents filled some of the gaps in the official documentation, but also revealed Intel's enclave licensing scheme, which has troubling implications.

After learning about the SGX implementation and inferring its design constraints, we discarded our draft proposals for defending enclave software against cache timing attacks. We concluded that it would be impossible to claim to provide this kind of guarantee given the design constraints and all unknowns surrounding the SGX implementation. Instead, we applied the knowledge that we gained to design the MIT Sanctum processor.

Sanctum shows that strong provable isolation of concurrent software modules can be achieved with low design complexity and little overhead.
This approach provides strong security guarantees against an insidious software threat model
including cache timing and memory access pattern attacks.
With the design of Sanctum, we hope to enable a shift in discourse in secure hardware architecture away from plugging specific security holes to a principled approach to eliminating attack surfaces.

This two part survey and analysis describes our findings while studying SGX and designing Sanctum. We hope that it will help fellow researchers understand the breadth of issues that need to be considered before accepting a trusted hardware design into a trusted computing base. We also hope that our work will prompt the research community to demand more transparency and open design from the vendors who ask us to trust their hardware.
