Reflections on trusting SGX

The security community will remember the year of 2018 as the year of speculative execution attacks. Meltdown and Spectre, the recent Foreshadow (L1TF in Intel’s terminology), and their variants demonstrate how the immense processor design complexity, perpetual drive for higher performance, and subtle hardware-software interactions — all collude to create a major system security earthquake that is shaking the whole industry.

Foreshadow stands out in that it wreaks havoc on Intel SGX, Intel’s recent instruction set extension for building trusted execution environments, which has been envisioned as a stronghold of security in future computing systems.

In this blog I highlight the important differences between Foreshadow and other speculative execution attacks, and raise a few questions that require much more than just a technical solution.

Background: SGX

Software Guard eXtensions (SGX) are a recent addition to the X86 instruction set that enable trusted and isolated execution of selected sections of application code in hardware containers called enclaves. An enclave acts as a reverse sandbox: its private memory and execution state are encrypted, and thus cryptographically isolated from any software outside the enclave, including an OS and/or a hypervisor, yet the code running in the enclave may access untrusted memory of the owner process.

The power of SGX is rooted in its ability to defend against a very strong attacker. SGX defines the CPU (including all the caches) as the only trusted component in the system. At the hardware level, the enclave memory is encrypted and integrity-protected in DRAM but in the caches it appears in clear text.

In addition, SGX provides tools to extend the trust from hardware into individual user-provided software modules via remote attestation: it enables a remote party to reliably validate the authenticity of the SGX hardware and software running in the enclave.

Foreshadow and L1TF

Foreshadow is a speculative execution attack that circumvents the SGX memory isolation and allows the attacker to read all the enclave memory in the clear. The implications of this attack are profound as it undermines the very essence of the SGX security guarantees. Worse, the attack breaks the SGX remote attestation mechanism, which in itself relies on SGX hardware protection, allowing the attacker to trick the remote attestation such that a fake enclave will be attested as a genuine one. The details of the attack and a thorough analysis can be found here .

Our team reported the attack to Intel in January 2018 as part of the responsible disclosure. Intel’s internal investigation then revealed that the actual security problem is not limited to SGX.  The attack, dubbed by Intel as L1 Terminal Fault , also affects memory protection between the virtual machine and the host, between any two processes, and of the System Management Mode (SMM).

Intel explains that the attack is possible due to the omission of the memory protection checks in the speculative execution path invoked as part of the access to a virtual memory page which has non-present or reserved bits turned on (thus causing a Terminal Fault). If the data stored in the physical frame allegedly mapped to that page is still found in L1, the transient instructions in the speculative execution path may read the data in the cache using the speculated physical address, which in turn is deterministically inferred from the respective virtual page table. This enables the attacker to read specific physical addresses of interest.

Observations

• Foreshadow causes major collateral damage to the whole SGX ecosystem . Specifically, the remote attestation mechanism involves Intel’s own management software that itself runs in enclaves and therefore is fully reliant on the SGX hardware guarantees. When Foreshadow breaks the SGX confidentiality guarantees, it causes a snowball effect: the secrets stored in the Intel management (architectural) enclaves get into the attacker’s hands, which in turn allows her to create fake enclaves, thereby ruining the SGX remote attestation functionality. Thus, SGX hardware is a single-point-of-failure of the entire SGX security system.
• Foreshadow and L1TF show that speculative execution attacks may work across virtual memory domain boundaries . This is different from Meltdown and Spectre which are confined to the virtual address space of a single process (even though Spectre  leaks data across processes via side channels).
• There is a natural question whether Foreshadow is an actual bug (like Meltdown) or an instance of the dubious choice in the security-vs-speed tradeoff (like Spectre). It seems that the former is closer to the truth. Intel suggests (as one of the mitigations) to zero out the physical address in the respective page table entry which causes the terminal fault. This implies that during the speculative execution, the processor reads the part of the page table entry that corresponds to the address bits (which Intel refers to as address speculation for some reason), but silently ignores all the other bits that might indicate that the mapping is no longer valid.
• SGX probably fell victim to the speculative execution bug that affects the X86 processo r that SGX builds upon. It is unclear whether the attack could have been thwarted by the SGX hardware logic itself. On the other hand, the attack would have been impossible if the processor running the enclave would have used caches exclusively. This is a point in favor of proponents of complete hardware isolation of security-sensitive processors from the main CPU.
• Even though a Foreshadow patch was promptly deployed in firmware, and undoubtedly will be fixed in the next processor generations, the successful attack on SGX created unrecoverable ripples in unexpected places . For example, it led to an interesting debate in the cryptocurrency community between those proposing to rely on hardware security guarantees to ensure the correctness of the distributed system, versus those who favor more complex yet provable software protocols.

Concerns and questions

Intel remains fairly secretive of the nature of the problem that enabled Foreshadow and L1TF. The high level description they provide seems opaque and deliberately simplified for a non-technical audience. It is hard to understand what went wrong and why.  Understandably, Intel focuses on the attack symptoms for immediate mitigations.  But the lack of any detailed and plausible explanation of the attack is disconcerting, in particular because we know that the actual system behavior is much more complex than portrayed in Intel’s technical briefs. For example, the attack works only when specific bits in the Page Table Entry are used to trigger the terminal fault, but does not work with others. Can we be sure that the symptomatic mitigations proposed so far will be enough? Why were Meltdown mitigations ineffective here? after all,  the core issues seem similar. Are they?

Taking a step back from the technical aspects, it is somewhat worrisome to realize that we are entirely dependent on hardware vendors to properly handle these types of critical security issues, and not only from the perspective of actually fixing them, but also in terms of dealing with pre-public disclosure efforts to mitigate the broader effects of the attack when disclosed to public.

For example, during the 8 months of the disclosure embargo, Intel presumably notified a few key industry players, but chose to keep us (the researchers) out of the loop. Earlier, there were complaints in the Linux community  that different vendors could not cooperate to develop software mitigations for Meltdown, but it may well be that the same “divide-and- conquer”  policy took place in the case of Foreshadow.  Clearly, Intel’s strategy serves its own interest, but should that strategy be at Intel’s sole discretion given the broad impact such attacks may have?  Should not there be something like a “World Health Organization” for CPU hardware security issues that can take the disclosure of such severe security problems under its own control?

The SIGARCH community seems to be exactly the right place to support and lead the way in establishing such organizations. What do people think about this?  Leave comments!

About the Author: Mark Silberstein is an Assistant Professor in the Electrical Engineering Department at the Technion – Israel Institute of Technology, where he heads the Accelerated Computer Systems Lab.

Acknowledgements

I thank all the other members of the team that co-authored the Foreshadow paper for the feedback and insights: Marina Minkin, Yuval Yarom, Daniel Genkin, Ofir Weisse, Jo Van Bulck, Baris Kasikci, Raul Strackx, Tom Wenisch, and Frank Piessens.  Discussions with Mattan Erez helped analyze the real plausible explanations of the attack. The idea of a global oversight body for hardware security attacks  was recently raised by Jon Masters of RedHat. The blog title is a paraphrase of the infamous “Reflections on Trusting Trust”  Turing Award Lecture title by Ken Thompson.