Top Picks

Breaking Protection and the SGX Ecosystem with

Jo Van Bulck Frank Piessens Katholieke Universiteit Leuven Katholieke Universiteit Leuven Marina Minkin Mark Silberstein University of Michigan Technion–Israel Institute of Technology Ofir Weisse Thomas F. Wenisch University of Michigan University of Michigan Daniel Genkin Yuval Yarom University of Michigan University of Adelaide and Data61, CSIRO Baris Kasikci Raoul Strackx University of Michigan Katholieke Universiteit Leuven

Abstract—Foreshadow is a attack that allows adversaries to subvert the security guarantees of ’s Software Guard eXtensions (SGX). Foreshadow allows access to data across boundaries, and allows virtual machines (VMs) to read the physical memory belonging to other VMs or the hypervisor.

& OVER THE PAST year and a half, speculative have gone from a hypothetical possibility to a execution attacks-–attacks that subvert memory very real threat.1,2 These attacks allow software to protection by exploiting the speculative execution exploit microarchitectural flaws, wherein specula- features of modern out-of-order processors— tive wrong-path instructions are allowed to access memory in violation of architectural protection guarantees. For example, the Meltdown flaw2 Digital Object Identifier 10.1109/MM.2019.2910104 allows the user-level code to access kernel Date of publication 15 April 2019; date of current version 8 memory locations that are mapped into the pro- May 2019. cess address space but are restricted to privileged

66 0272-1732 ß 2019 IEEE Published by the IEEE Society IEEE Micro accesses only. Speculative execution attacks that data accessed during execution cannot be exploit the transient data access of wrong-path observed by the privileged cloud vendor. instructions by leaking secret data into a side chan- To support such private and secure code exe- nel. Side-channel attacks exploit subtle timing var- cution, SGX provides isolated execution environ- iations in program execution resulting from state ments, called enclaves, which offer confidentiality changes in microarchitectural (i.e., unspecified in and integrity guarantees to programs running the instruction set architecture) structures or con- inside them. Enclaves are secure even in the pres- tention on microarchitectural CPU resources to ence of a malicious , hypervisor, extract otherwise-unavailable secret information. or firmware. Enclaves are also resilient to physical vendors have invested signific- attacks from outside the CPU package, such as ant effort3 to roll out mitigations for the earliest probes on the memory . discovered speculative execution attacks, Melt- At a high level, SGX achieves these strong secu- down2 and Spectre.1 rity guarantees by encrypting the enclave memory Unfortunately these and protecting it with a secure authentication code, measures are inef- Foreshadow allows the making the associated cryptographic keys inaccessi- fective against Fore- attacker code direct ble to software. Finally, SGX provides a remote attes- shadow (also known access to arbitrary tation mechanism. Attestation allows enclaves to as “L1 Terminal physical addresses prove to remote parties that the code and data Fault (L1TF)” in through speculative upon which they operate are unmodified and, impor- Intel’s product liter- wrong-path execution. tantly, the processor upon which they execute is a ature4). Foreshadow genuine (hence, presumed secure) Intel processor. allows the attacker code direct access to arbitrary Notwithstanding its strong security guaran- physical addresses through speculative wrong- tees, SGX does not protect against microarc- path execution. Unlike previously disclosed specu- hitectural side-channel attacks. Since their lative execution attacks, this vulnerability fully sub- introduction over a decade ago, microarchitec- verts the isolation provided by the traditional tural attacks have been used to break numerous virtual memory abstraction, upon which the classic cryptographic implementations, track program security mechanisms of operating systems and vir- behavior, and create covert communication chan- tual machines are built, by allowing attackers to nels. Since SGX’s release, there have been many access data that has no virtual address mapping. works that demonstrated side-channel attacks on The key restriction of Foreshadow/L1TF is that as SGX enclaves (e.g., work presented by Xu et al.5)— far as we know, only physical addresses cached in exploiting vulnerabilities that already exist in the L1 data can be exfiltrated. However, as enclaves’ code to leak sensitive data. we show, there are often mechanisms available to Instead, our investigation was motivated by cause the processor to load desired data into the following question: Can an adversary extract cache; in some circumstances, entire address secret data from an enclave’s address space spaces can be exfiltrated. when the code running in that enclave does not itself have any security vulnerabilities? FORESHADOW-SGX Next, given the importance of SGX remote Our international collaboration discovered attestation we asked: What are the implications Foreshadow/L1TF in the context of efforts to inves- of such security breaches on the SGX integrity tigate the security of Intel’s Software Guard guarantees? Can an adversary using a side chan- eXtensions (SGX). SGX is a set of architectural nel erode trust in SGX remote attestation? extensions, which collectively provide strong secu- We answer both questions in the affirmative. rity guarantees to software running in the presence of powerful adversaries. SGX promises secure execution on adversary-controlled machines. OUR CONTRIBUTIONS For example, in the context of cloud computing, Breaking SGX’s Confidentiality SGX guarantees that the processor executes the Foreshadow-SGX exploits the speculative unmodified code provided by the customer and execution features present in all SGX-enabled

May/June 2019 67 Top Picks

Intel CPUs to read the entire address space of Exploiting SGX’s Privacy Guarantees victim enclaves. Crucially, unlike previous Spec- We note that SGX’s attestation protocol is tre-style speculative execution attacks on SGX, designed with privacy in mind and does not our attack does not require any form of coopera- reveal the identity of the attesting machine to tion or particular flaw in the victim enclave. the remote verifying party. As such, the remote In fact, our attack reads all the secrets of the party has no way of telling which keys were used victim enclave without requiring that enclave to for attestation. Consequently, until revoked by execute any instruction. Intel, even a single leaked attestation key can be used for all malicious simulators, without the remote parties being able to distinguish them Breaking the Integrity of Sealed Data from genuine SGX machines. Thus, the leak of Going beyond the attacks on the SGX confi- even a single key jeopardizes the trustworthi- dentiality properties, we show that Foreshadow ness of the entire SGX ecosystem. also compromises SGX’s long-term storage integ- rity guarantees. Specifically, beyond secure Demonstrating the Brittleness of the SGX computation, SGX also provides private and Ecosystem authenticated long-term storage, which is imple- To the best of our knowledge, our attack is mented via a special sealing application program- the first direct attack on the confidentiality of ming interface (API). This storage mechanism SGX enclaves that makes no assumptions about allows enclaves to encrypt and verify data stored code running in a victim enclave. By leveraging by the (untrusted) operating system. this attack, the adversary may break the integ- As we show, we can use our attack on SGX’s rity of the SGX long-term storage and the trust- confidentiality to extract the sealing key from a worthiness of the remote attestation protocol. victim enclave that uses the SGX sealing mecha- As such, our work highlights the brittleness of 11 nism. After recovering the sealing key, we use the current SGX design because a flaw in confi- it to unseal and read the sealed information, dentiality leads to a cascading set of compro- then modify and reseal it. As SGX provides no mises that undermine the root of trust in the means to detect such a change, the victim con- ecosystem. sequently operates on data corrupted by the attacker. First real demonstration of the L1TF vulnerability Our international collaboration reported Breaking Remote Attestation our proof-of-concept exploit of SGX to Intel. Finally, we turn our attention to SGX’s remote Prompted by our reports, Intel subsequently dis- attestation mechanism, which allows an enclave covered and revealed the underlying L1TF micro- to prove to a remote party that it has been ini- architectural flaw, with consequences much tialized correctly and is executing on a genuine broader than SGX, including subverting memory (presumably secure) Intel processor. protections essential for cloud computing. As we show, we can mount our attacks on enclaves written by Intel and extract their sealing BACKGROUND—SIDE-CHANNEL key. Using the extracted sealing key, we then AND SPECULATIVE EXECUTION unseal the persistent storage of the SGX Quoting ATTACKS Enclave, which contains the machine’s private We briefly explain past side-channel and spe- attestation key. With this key, we can construct culative execution attack mechanisms. malicious SGX simulators that can forge the attes- tation process, masquerading as enclaves that The FlushþReload Attack are allegedly running on genuine Intel processors FlushþReload7 is a cache-based microarchi- with the SGX security guarantees. As the simu- tectural attack technique that detects access to lated enclaves do not offer any security guaran- a shared memory location. The technique com- tees, this attack undermines the trustworthiness prises two main operations. The flush operation of SGX’s attestation mechanism. evicts the contents of a monitored memory

68 IEEE Micro location from the cache. Typically, the eviction is done via a dedicated instruction, such as the CLFLUSH instruction. The reload operation later measures the time it takes to access the monitored location. Based on this time, the attacker determines whether the monitored location was loaded into the cache in the interim since the Figure 1. Rogue data cache loads (Meltdown) can be leveraged to leak flush operation. sensitive data from more privileged security layers. In a typical attack scenario, an attacker flushes one or more moni- tored locations. The attacker then either exe- processor may speculatively execute the wrong- cutes an operation it wants to analyze or waits path instructions that follow the kernel memory until the operation is naturally executed by read. By placing a gadget that sends the value the victim. The attacker then reloads the moni- forwarded by the faulting load through a covert tored locations while recording the amount channel, an attack can retrieve the contents of of time required to perform the reload. As the that address even for accesses that violate mem- analyzed operation accesses (and thereby ory protection. caches) some of the monitored locations, but Figure 1 illustrates a toy Meltdown example not others, the attacker is then able to learn wherein an attacker exfiltrates one bit of infor- information about the victim memory access mation across privilege levels. In the first step, pattern. FlushþReload has been extensively the attacker attempts to read data from a more used for side-channel attacks and is used as a privileged protection layer, which will eventually reliable covert channel in speculative execution lead to a memory protection exception. But, the attacks.1,2 subsequent dependent wrong-path instructions can receive the value from the read—even Spectre and Meltdown though it will eventually fault—and encode Spectre and Meltdown attacks perform secrets in the CPU cache. The example uses a unauthorized data access while executing reliable FlushþReload7 covert channel, where wrong-path instructions in vulnerable process- the wrong-path instruction sequence loads a ors. When the CPU squashes these instru- predetermined memory location into the cache, ctions, it does not fully revert all the side dependent on the least significant bit of the ker- effects they have on microarchitectural state, nel data. When the speculation resolves, the and in particular, processor cache state. Spec- load faults and an exception handler is invoked. tre and Meltdown1,2 exploit these side effects In this example, we show the attacker code for to leak information across protection domains. retrieving the secret within the exception han- The attacks cause the CPU to speculatively dler, wherein the adversary retrieves the secret execute a code gadget, which implements the bit by carefully measuring the amount of time it transmitting side of a covert channel, sending takes to reload the predetermined memory information that would otherwise be unavail- location. able to the receiver. The Meltdown attack, however, does not allow Specifically, the Meltdown attack (Figure 1) is attackers to perform unauthorized reads from possible because vulnerable processors handle memory protected by SGX. In contrast to Melt- memory exception faults at instruction retire- down, which relies on a page fault after accessing ment rather than as instructions execute, creat- kernel space, accessing SGX memory does not pro- ing a window of vulnerability where data may be duce a page fault. Instead, such accesses trigger forwarded to wrong-path instructions that follow abort page semantics and the load instead returns the faulting access. So, when a user program the dummy value 0xFF, precluding wrong-path attempts to read from a kernel address, the code from leaking a secret value.

May/June 2019 69 Top Picks

BACKGROUND—INTEL SGX the enclave’s initial code and data. Besides Memory Isolation this content-based identity (MRENCLAVE), each SGX enclaves live in the virtual address space enclave also features an alternative, author- of a conventional user process, but their physical based identity (MRSIGNER) that includes a hash memory isolation is strictly enforced in hardware. of the enclave developer’s public key and ver- This separation of responsibilities ensures that sion information. Upon enclave initialization, enclave-private memory can never be accessed and before it can be entered, the processor veri- from outside, while untrusted system software fies the enclave’s signature and stores both remains in charge of enclave memory manage- MRENCLAVE and MRSIGNER measurements at a ment (i.e., allocation, eviction, and mapping secure location, inaccessible to software—even of pages). An SGX-enabled CPU furthermore veri- from within the enclave. Thus, an enclave’s fies the untrusted address translation process, initial measurement is unforgeable and can be and may signal a page fault when traversing attested to other parties or used to access the untrusted page tables, or when encountering sealed secrets. rogue/illegal enclave memory mappings. Subse- Each SGX-enabled processor is shipped quent address translations are cached in the with a platform master secret stored within processor’s TLB. The processor performs a TLB the processor and exclusively accessible to shootdown for enclave entries upon enclave exit key derivation hardware. Enclaves make use of to prevent access to enclave memory from code the key derivation facility by using the SGX executing outside the enclave. Any attempt to instruction EGETKEY. For instance, enclaves directly access private pages from outside the can invoke EGETKEY to generate sealing keys enclave results in abort page semantics: reads based on either the calling enclave’s content- return the value 0xFF and writes are ignored. based (MRENCLAVE) or developer-based SGX further protects enclaves against moti- (MRSIGNER) identity. Such sealing keys can be vated adversaries that exploit Rowhammer used to securely store persistent data outside DRAM bugs, or resort to physical cold boot the enclave, for later use by either the exact attacks. A hardware-level memory encryption same enclave (MRENCLAVE) or the same engine8 transparently safeguards the integrity, developer (MRSIGNER). confidentiality, and freshness of enclaved code and data while it resides outside of the processor Architectural Enclaves package. That is, any access to main memory is As certain policies are too complex to realize first authenticated and decrypted before cached in hardware, some key SGX aspects are them- on chip in plaintext. selves implemented as Intel-signed enclaves. Enclave code can only be invoked through a Specifically, Intel provides: 1) a launch enclave, few predefined entry points. The EENTER and which controls entry into other enclaves; 2) a EEXIT instructions transfer control between provisioning enclave to supply the long-term the untrusted host application and an enclave. platform attestation key; and 3) a quoting In case of a fault or external interrupt, the pro- enclave, which uses the asymmetric platform cessor executes the asynchronous enclave attestation key to sign local attestation reports exit procedure, which securely stores and for a remote stakeholder. wipes CPU register contents before transferring control to the untrusted operating system. A ATTACK MODEL AND OBJECTIVES dedicated ERESUME instruction allows the unprotected application to resume a previously Adversary Capabilities interrupted enclave. Whereas most existing SGX attacks require the full potential of a kernel-level attacker, Enclave Measurement we show that the basic Foreshadow attack can While an enclave is prepared for launch by be mounted entirely from user space. Our untrusted system software, the processor com- attack essentially implies that current SGX poses a secure hash (i.e., a “measurement”) of implementations cannot even protect enclave

70 IEEE Micro Figure 2. Basic overview of the Foreshadow attack to extract a single byte from an SGX enclave.

secrets from unprivileged adversaries, for Breaking SGX Sealing and Attestation instance co-residing cloud tenants. Addition- The SGX design allows enclaves to “request a ally, to further improve the success rate of secure assertion from the platform of the our attack for root adversaries, we contribute enclave’s identity [and] bind enclave ephemeral 11 various optional noise-reduction techniques data to the assertion.” While we cannot break that exploit full control over the untrusted integrity of enclaved data directly, we leverage operating system, in line with SGX’s privileged Foreshadow to extract enclave sealing and attes- attacker model. tation keys. The former comprises the confidenti- Crucially, in contrast to all previously ality and integrity of sealed secrets, whereas the published SGX side-channel attacks and existing latter can be used to forge attestation reports. Spectre-style speculative execution attacks5 Our attack on Intel’s trusted quoting enclave for against SGX enclaves, Foreshadow does not remote attestation further collapses confidential- require any side-channel vulnerabilities, code ity and integrity guarantees for remote computa- gadgets, or even knowledge of the victim tions and secret provisioning. enclave’s code. In fact, as long as secrets reside in the enclave’s address space, our attack THE FORESHADOW ATTACK does not even require the victim enclave’s The basic Foreshadow attack extracts a single execution. byte from an SGX enclave in three distinct phases, visualized in Figure 2. As part of the attack prepara- Breaking SGX Confidentiality tion, the untrusted enclave host application first The Intel SGX documentation unequivocally allocates a covert channel array 1 with 256 slots, states that “enclave memory cannot be read each measuring 4 KB in size (padded to avoid hard- or written from outside the enclave regardless ware prefetcher interactions). In Phase I of the of current privilege level and CPU mode (ring3/ attack, plaintext enclave data are loaded into the user-mode, ring0/kernel-mode, SMM, VMM, cache. With a malicious OS, the relevant cache line or another enclave).”9 As Foreshadow compro- can be fetched easily without the victim running. mises confidentiality of production enclave Next, Phase II dereferences the enclave secret and memory, this Intel SGX security objective speculatively executes a wrong-path instruction is broken. sequence that loads a secret-dependent line into Our basic attack requires enclave secrets to the cache. Finally, Phase III acts as the receiving resideintheL1datacache. For root adversaries, end of the FlushþReload covert channel and we furthermore contribute an innovative tech- reloads the array slots to determine the secret byte. nique that leverages SGX’s paging instructions to prefetch arbitrary enclave memory into the L1 Phase I: Caching Enclave Secrets data cache without requiring the victim enclave’s In contrast to previous research,1 and consis- cooperation. When combined with a state-of-the- tent with Intel’s vulnerability disclosures,4 we art enclave execution control framework, such as found consistently that enclave secrets never SGX-Step,10 our root attack can dump the entire reach the wrong-path instructions in Phase II memory and register contents of a victim enclave if they do not already reside in the L1 cache. at any point in its execution. The first phase of the basic Foreshadow attack

May/June 2019 71 Top Picks

executes the victim enclave 2 to load plaintext corresponding page table entry, such that secrets into cache. accesses to the page lead to a fault. To ensure the successful exfiltration of the secret byte via Bringing Data Into the L1 Cache on Behalf of the covert channel array, we flush the slots from the Victim the cache 4 . Finally, the attacker dereferences The SGX design explicitly relies on an secret_ptr and executes the wrong-path instruc- untrusted OS for oversubscribing the limited tion sequence 5 . encrypted physical memory, called the enclave page cache (EPC). To do so, the untrusted OS Phase III: Receiving the Secret may make use of the privileged EWB and When the faulting load retires, the processor ELDU SGX instructions that respectively copy rolls back subsequent wrong-path instructions, encrypted 4 KB enclave pages out of, and back discarding uncommitted register changes and into the EPC. We observed that, when decrypting raises a page fault. After the fault is caught by an encrypted enclave page, the ELDU instruction the operating system, the attacker’s user-level loads the entire page as plaintext into the CPU’s exception handler is called. Here, she carefully L1 cache. Thus, Foreshadow can bring the vic- measures 6 the timing to reload each slot. If tim’s data into the L1 cache without having the the wrong-path instruction sequence reached victim execute any instructions. the step that touches the array slot at the secret index, the corresponding cache line will hit, Phase II: Wrong-Path Execution resulting in a much shorter access time. In the second phase, we dereference secret_ptr and speculatively execute a wrong-path instruc- Implications tion sequence to exfiltrate the secret. Under SGX, Foreshadow allows dumping the entire abort page semantics normally prevent wrong- address space of SGX enclaves at any time. We suc- path instructions from observing values that orig- cessfully used Foreshadow to extract the launch inate in enclave memory—they instead observe and attestation secrets protected by the Intel’s only the dummy value 0xFF. However, Fore- Launch and Quote enclaves. Extracting the private shadow circumvents this protection by taking attestation keys from the Quote Enclave allowed advantage of the fact that abort page semantics us to sign counterfeit attestation proofs, which apply only after the legacy page table permission were approved by Intel Attestation Services. check succeeds without triggering a page fault. Specifically, the attacker removes access permis- sions from the enclave’s memory to cause, as ATTACKING INTEL’S ENCLAVES dubbed by Intel, a translation terminal fault.4 Whereas SGX is largely realized in hardware and Despite the failed translation, the processor’s , Intel implements certain critical func- load unit nevertheless forms a physical address tionality in software through dedicated architectural using the faulty translation and accesses the L1 enclaves. These enclaves are part of the trusted data cache. Consequently, the actual value at computing base and were written by experts with the corresponding physical address, rather than detailed knowledge of SGX. No obvious security a dummy value, is propagated from L1 to depen- flaws have ever been found, and Intel’s architec- dent wrong-path instructions. In our running tural enclaves implement various defense-in-depth example, we proceed by revoking 3 all access mechanisms. For example, even though private permissions to the enclave page we wish to read memory should never leak from enclaves, sensitive via the mprotect user space API: data are erased as soon as possible.

mprotect(secret_ptr &0xfff, 0x1000, Attack and Exploitation PROT_NONE); SGX remote attestation relies on the SGX seal- ing mechanism to encrypt and store the attes- We verified that the above mprotect system tation key on disk. An attacker with an attestation call simply clears the “present” bit in the key can sign arbitrary enclave measurements,

72 IEEE Micro which are the SHA-256 of the enclave code. Using to access kernel memory (CVE-2018-3620) or by Foreshadow, the attacker can steal the quote malicious guest virtual machines to access mem- enclave sealing key. After unsealing the attes- ory belonging to the hypervisor and other guest tation key, the attacker can sign rogue enclave machines (CVE-2018-3646). measurements and forge proofs to Intel and exter- Importantly, where previous Meltdown1 nal parties that the enclave runs on genuine attacks access unauthorized supervisor data hardware (see the work given by Van Bulck et al. within the attacker’s virtual address space, 12 for details). Foreshadow-NG variants access unauthorized physical memory Impact locations that are not mapped in the Foreshadow and other The ability to spoof remote attestation speculative execution attacker’s virtual responses has profound consequences. Attes- attacks exploit subtle address space. As tation is typically the first step to establish a microarchitectural such, Foreshadow- secure communication channel, for example, via races and, therefore, NG fully escapes the an authenticated Diffie–Hellman key exchange.11 are highly elusive. virtual memory Using our rogue quoting service, a network-level sandbox—page adversary (e.g., the untrusted host application) table isolation is no longer sufficient to prevent can trivially establish a man-in-the-middle posi- unauthorized memory access. tion to read and modify all traffic between a vic- Crucially, page table isolation mitigations that tim enclave and a remote party. All remotely are effective against Meltdown do not prevent provisioned secrets can now be intercepted, Foreshadow-type L1TF attacks. Foreshadow, without even executing the victim enclave or therefore, brings a paradigm shift in the way we requiring detailed knowledge of its internals— should think about mitigating Meltdown-like effectively eliminating the ability to trust remote threats: merely unmapping secrets from an SGX-based cloud services. For instance, an end- untrusted application’s address space is an insuf- user might be fooled to reveal his private crypto ficient countermeasure. currency key to a remote SGX-based wallet while in fact the private key is intercepted by the adversary. Apart from such confidentiality con- Final thoughts cerns, adversaries can also fabricate arbitrary Foreshadow and other speculative execution remote SGX computation results. attacks exploit subtle microarchitectural races and, therefore, are highly elusive. For example, we found that seemingly insignificant variations BROADER IMPLICATIONS OF of the covert channel implementation may cause FORESHADOW / L1TF the attack to succeed or fail. Unfortunately, due We reported our Foreshadow-SGX findings to the scarcity of public information about the to Intel in January 2018, describing how we processor architecture, we can only guess what defeated enclave memory isolation, sealing, and real architectural flaws underlie the attack. Yet, attestation guarantees (CVE-2018-3615). Subse- the higher level insight is independent of the quent investigation by Intel4 identified the root hardware implementation: speculation across cause for Foreshadow as the L1TF vulnerability. memory protection boundaries is dangerous in Unfortunately, L1TF has much broader and more the presence of hardware side channels, and direr consequences than leaking enclave memory, should be avoided or explicitly safe-guarded for it essentially allows dumping the entire against potential attacks. contents of the L1 data cache, regardless of the owner of the data. In particular, Intel identified two closely related variants of Foreshadow, which ACKNOWLEDGEMENTS we collectively call Foreshadow-Next Generation This work was supported in part by the (Foreshadow-NG).6 At a high level, Foreshadow-NG Research Fund KU Leuven, the Technion Hiroshi might be exploited by unprivileged applications Fujiwara cyber security research center, the Israel

May/June 2019 73 Top Picks

cyber bureau, the National Science Foundation 11. F. McKeen et al., “Innovative instructions and software (NSF) under Awards 1514261 and 1652259, the model for isolated execution,” in Proc. 2nd Int. financial assistance award 70NANB15H328 from Workshop Hardware Archit. Support Security Privacy, the U.S. Department of Commerce, the National 2013, Paper 10. Institute of Standards and Technology, the 2017- 12. J. Van Bulck et al., “Foreshadow: Extracting the keys to 2018 Rothschild Postdoctoral Fellowship, and the Intel SGX kingdom with transient out-of-order the Defense Advanced Research Project Agency execution,” in Proc. 27th USENIX Security Symp., 2018, (DARPA) under Contract FA8650-16-C-7622. The pp. 991–1008. work of J. Van Bulck and R. Strackx was supported by a grant from the Research Foundation—Flan- Jo Van Bulck is currently a PhD student in com- ders (FWO). puter science at imec-DistriNet, Katholieke Universi- teit Leuven, Belgium. Contact him at jo.vanbulck@cs. & REFERENCES kuleuven.be.

1. P. Kocher et al., “Spectre attacks: Exploiting speculative Marina Minkin is currently a PhD student in execution,” in Proc. 40th IEEE Symp. Security Privacy, computer science and engineering at the University of 2019. Michigan. The work was performed when she was 2. M. Lipp et al., “Meltdown: Reading kernel memory from with Technion—Israel Institute of Technology. Contact her at [email protected]. user space,” in Proc. USENIX Security Symp., 2018, pp. 973–990. Ofir Weisse is currently a PhD student in computer 3. Intel, “Speculative execution side channel mitigations.” science and engineering at the University of Michigan. 2018. [Online]. Available: https://software.intel.com/ Contact him at [email protected]. security-softwareguidance/api-app/sites/default/files/ 336996Speculative-Execution-Side-ChannelMitigations. Daniel Genkin is an assistant professor of com- pdf puter science and engineering at the University of 4. Intel, “Deep dive: Intel analysis of L1 terminal fault.” Michigan. Contact him at [email protected]. 2018. [Online]. Available: https://software.intel.com/ Baris Kasikci is an assistant professor of com- security-software-guidance/insights/deep-dive-intel- puter science and engineering at the University of analysis-l1-terminal-fault Michigan. Contact him at [email protected]. 5. Y. Xu, W. Cui, and M. Peinado, “Controlled-channel attacks: Deterministic side channels for untrusted Frank Piessens is a professor of computer science operating systems,” in Proc. IEEE Symp. Security at imec-DistriNet, Katholieke Universiteit Leuven, Privacy, 2015, pp. 640–656. Belgium. Contact him at [email protected]. 6. O. Weisse et al., “Foreshadow-NG: Breaking the virtual memory abstraction with transient out-of-order Mark Silberstein is an associate professor of execution,” 2018. [Online] Available at: https:// electrical engineering at Technion—Israel Institute of foreshadowattack.eu/foreshadow-NG.pdf Technology. Contact him at [email protected]. 7. Y. Yarom and K. Falkner, “FLUSHþRELOAD: A high Thomas F. Wenisch is an associate professor of resolution, low noise, L3 cache side-channel attack,” in computer science and engineering at the University Proc. 23rd USENIX Security Symp., 2014, pp. 719–732. of Michigan. Contact him at [email protected]. 8. S. Gueron, “Memory encryption for general-purpose processors,” IEEE Security Privacy, vol. 14, no. 6, Yuval Yarom is a senior lecturer in computer pp. 54–62, Nov. 2016. science at the University of Adelaide and Data61, 9. Intel, “SGX SDK for Linux.” 2018. [Online]. Available: CSIRO. Contact him at [email protected]. https://01.org/sites/default/files/documentation/intel_ sgx_sdk_developer_reference_for_linux_os_pdf.pdf Raoul Strackx is a postdoctoral research fellow 10. J. Van Bulck, F. Piessens, and R. Strackx, “SGX-Step: in computer science at imec-DistriNet, Katholieke A practical attack framework for precise enclave Universiteit Leuven, Belgium. Contact him at execution control,” SysTEX, Shanghai, China, 2017. [email protected].

74 IEEE Micro