Foreshadow-NG: Breaking the Virtual Memory Abstraction with Transient
Out-of-Order Execution
Revision 1.0 (August 14, 2018)

Ofir Weisse3 , Jo Van Bulck1 , Marina Minkin2 , Daniel Genkin3 , Baris Kasikci3 , Frank Piessens1 ,Mark Silberstein2 , Raoul Strackx1 , Thomas F. Wenisch3 , and Yuval Yarom4
1 imec-DistriNet, KU Leuven, 2 Technion, 3 University of Michigan, 4 University of Adelaide andData61
Abstracttion requires different computational tasks belonging toseparate security domains to be isolated from each otherand prevented from reading each other’s memory. In
modern computer architectures this is typically achieved
via hardware-backed virtual memory, where each process has its own separate virtual address space. Whena process accesses some memory location in its virtual
address space, the hardware translates the location’s address into the corresponding physical address. Beyond
the convenience of simulating a memory space muchlarger then the system’s physical memory and the avoidance of address collisions across virtual address spaces,
virtual memory serves as an effective security mechanism. Specifically, because addresses used by a process
are always translated using the hardware-based translation mechanism, on a correctly functioning hardware, aprocess cannot “name” physical addresses belonging toother processes, let alone access them.
Unfortunately, the recent wave of speculative execution CPU vulnerabilities has eroded the trust in basic design principles of memory isolation via virtual memory.
Although the nominal CPU state respects process isolation via virtual memory, the actual implementation often speculates past permission checks, thus allowing aprocess to transiently violate memory isolation and obtain sensitive information belonging to other processes.
While the CPU eventually rolls back the instructions it
incorrectly executed, by that time secrets may have already been leaked via microarchitectural side-channels.
By demonstrating how to read kernel data from user
space, the Meltdown attack [7] dismantled the memory
protection guarantees enforced by the x86 “supervisor”
page table attribute, allowing user space programs to exploit transient out-of-order execution to read data belonging to the operating system, as well as to other processes.
To mitigate Meltdown, operating systems and hypervisors had to be urgently patched so as to strictly separate the virtual address spaces used for kernel and user
data, thus eliminating the need for the deficient “super-

In January 2018, we discovered the Foreshadow transient
execution attack (U SENIX Security’18) targeting Intel
SGX technology. Intel’s subsequent investigation of ourattack uncovered two closely related variants, which wecollectively call Foreshadow-NG and which Intel refers
to as L1 Terminal Fault. Current analyses focus mostly
on mitigation strategies, providing only limited insight
into the attacks themselves and their consequences. The
aim of this report is to alleviate this situation by thoroughly analyzing Foreshadow-type attacks and their implications in the light of the emerging transient execution
research area.
At a high level, whereas previous generation
Meltdown-type attacks are limited to reading privileged
supervisor data within the attacker’s virtual address
space, Foreshadow-NG attacks completely bypass thevirtual memory abstraction by directly exposing cached
physical memory contents to unprivileged applications
and guest virtual machines. We review mitigation strategies proposed by Intel, and explain how Foreshadow-NG
necessitates additional OS and hypervisor-level defense
mechanisms on top of existing Meltdown mitigations.
Disclaimer. This is an evolving document, which
presents our understanding of Foreshadow / L1 Terminal
Fault attacks and their implications at the time of writing. Due to the recent disclosure of the attacks, and inparticular of Foreshadow-NG, our understanding may be
incomplete, and while we have done our best to verify
the correctness of the description, inaccuracies may havefallen. We aim to correct such inaccuracies and omissions in future revisions of this document.

1

Introduction

For decades, memory isolation has been one of the key
principles of computer system design. Memory isola1

CPU micro-architecture

visor” x86 page table attribute. While these patches imply performance-sapping address space changes on almost every system call and virtual machine exit, it was
generally believed that strictly maintaining separate user
and kernel address spaces was sufficient to neutralize
Meltdown-type threats.

Tag?

L1D

vadrs

1

Foreshadow. In January 2018, we reported Foreshadow [9], a novel Meltdown variant targeting Intel
SGX technology (CVE-2018-3615), which defeats enclave memory isolation, sealing, and attestation guarantees. Subsequent investigation by Intel [5] identified the root cause for Foreshadow as an L1 Terminal
Fault (L1TF) vulnerability. Unfortunately, L1TF hasmuch broader and more dire consequences than leaking enclave memory, for it essentially allows to dump
the entire contents of the L1 data cache, regardless ofthe owner of the data. In particular, Intel identified two
closely related variants of Foreshadow, which we collectively call Foreshadow-NG — Foreshadow Next Generation. At a high level, Foreshadow-NG might be exploitedby unprivileged applications for accessing kernel memory (CVE-2018-3620), or by malicious guest virtual machines to access memory belonging to the hypervisor andother guest machines (CVE-2018-3646).
Importantly, where previous Meltdown [7] attacks
dereference unauthorized supervisor data within the attacker’s virtual address space, Foreshadow-NG-type attacks variants exploit a subtle L1TF microarchitectural
condition that allows to transiently compute on unauthorized physical memory locations that are currently not
mapped in the attacker’s virtual address space view. As
such, Foreshadow-NG is the first transient execution attack that fully escapes the virtual memory sandbox—
traditional page table isolation is no longer sufficient toprevent unauthorized memory access.
Crucially, the aforementioned page table isolation
software mitigations by themselves cannot prevent
Foreshadow-type L1TF attacks. Foreshadow therefore
brings a paradigm shift in the way we should think about
mitigating Meltdown-type threats: merely unmapping
secrets from an untrusted application’s address space
now becomes a necessary but not a sufficient condition.

PT
walk?

guest
padrs

2

Pass to out-of-order

EPT
walk?

host
padrs

SGX?

3

EPCM fail3a

Figure 1: CPU address translation and L1 terminal
fault behavior: documented architectural view (bottom)
and undocumented micro-architectural transient execution interactions (top). 2• We compare Foreshadow-type attacks to previous
Meltdown-type transient execution vulnerabilities.
• We provide an initial description of defenses against
Foreshadow-type attack and argue that they requirea paradigm shift in traditional approaches of address
space isolation.
• We identify challenges for future work and an outlook of the L1TF / Foreshadow landscape.

2Computer Architecture Background

Address Translation. Whenever dereferencing a virtual (i.e., linear) memory address, modern Intel x86 processors [4] first perform a Translation Lookaside Buffer(TLB) lookup to establish the corresponding physical address. If there is no matching TLB entry, the processor must perform a page table walk to yield a Page Table Entry (PTE) containing the required physical memory address and access rights. The bottom half of
Figure 1 shows how after the conventional virtual-tophysical page table translation, an additional Extended
Page Table (EPT) walk may be needed, in case of a virtualized environment, to translate the guest physical memory address into the underlying machine’s host-physicalmemory address. Finally, Intel SGX-enabled processors further sanitize the resulting address translations tomake sure they abide by hardware-enforced enclave access control restrictions. If any of these three independent successive stages reports an access violation, a pagefault is eventually raised, and control flow is redirected
to an exception handler (or in case of Intel SGX, mostenclave memory violations are silently dropped by replacing memory loads with the abort page dummy value0xff).

Goals. With this report, we aim to complement Intel’s
official analysis [5] on L1 Terminal Faults with the following:• We discuss and analyze three Foreshadow attack
variants: Foreshadow-SGX, Foreshadow-OS, andForeshadow-VMM where the former was identified
by us in [9] and the two latter by Intel [5].1

2 PT: Page Table; EPT: Extended Page Table; EPCM: Enclave Page
1 We note that Intel refers to all of these as L1 Terminal Fault attacks.

Cache Metadata2

While the above CPU address translation process iswell-documented at the architectural level [4], modern processors implement largely non-transparent microarchitectural optimizations to speed up costly addresstranslations through parallelization and extra caches. In
this respect, previous research on Meltdown-type faultdriven attacks has revealed that Intel CPUs delay memory access violation checks until instruction retirement,
allowing unauthorized memory contents to still reachtransient out-of-order instructions ahead in the pipeline
before a page fault is eventually raised. The original
Meltdown attack exploits this time window to transiently
encode supervisor-only memory in the persistent microarchitectural state.

the micro-architectural level, causing the address translation process to abort before executing the architectural
EPT/SGX follow-up stages of Figure 1.
At the same time, however, the processor still derives
a physical address from the faulting PTE and attempts todecide whether the L1 data cache could serve the memory request (i.e., L1 hit). We hypothesize that Intel opted
to implement the L1 tag comparison in parallel with theaddress translation process for performance reasons.
As illustrated in the top half of Figure 1, data residing in the L1 cache is immediately forwarded to the transient out-of-order execution upon successful tag comparison. While desirable from a performance perspective,
this behavior also implies that when prematurely aborting the address translation process due to a terminal fault,
the transient instructions compute on unauthorized data.
Hence, as with plain Meltdown, the unauthorized memory request is properly blocked at the architectural level(by raising a terminal fault), but adversaries can still encode the results of secret-dependent computations at the
microarchitectural level.
Especially dangerous in this respect, is that the actual data being passed from the L1 cache to the out-oforder sequence solely depends on the resulting guest or
host physical address. We will explain below how a terminal fault during the address translation process canallow Foreshadow adversaries to bypass all three successive OS/VMM/SGX memory protection phases from
Figure 1.

CPU L1 Cache. Modern Intel CPUs [4, 2] use acarefully-crafted virtually-indexed, physically-tagged L1
cache design. As illustrated in the top half of Figure 1,
this allows the first step of the address translation to proceed in parallel with the L1 cache set lookup (as the latteris completely determined by the software-provided virtual address). After locating the correct L1 cache set,
however, the processor should still determine whether
any of the non-vacant ways within that set contain therequired data. For this, the CPU matches the (unique)physical address resulting from the address translation
process against an internal metadata tag stored alongeach of the individual ways. Only when one of the nonvacant ways contains the exact right physical address tag,is the data returned to the processor’s execution units(i.e., L1 hit).

3

3.2

In line with Intel’s official L1TF analysis [5], we consider three distinct Foreshadow/ Foreshadow-NG attack
variants, depending on the ability of the adversary.

Foreshadow-NG-type Attacks

We begin our description of Foreshadow-NG-type attacks by providing an overview on the L1 Terminal Fault
issue present in Intel processors, and describe three distinct Foreshadow-type attack variants that exploit the
L1TF issue, each with different adversary capabilities.

3.1

Adversary Capabilities

1. Foreshadow-OS. An unprivileged adversary withuser space code execution controls the virtual address input to the first page table walk. Such adversaries can cause terminal faults by merely waiting
for the OS to clear the PTE present bit in some PTE
entry when swapping a page out of memory to disk.
At this point, transient out-of-order instructions canbe used to read any cached contents located at thephysical address pointed by the PTE entry.

L1 Terminal Fault

Previous Meltdown attacks have only considered bypassing memory protection enforced by the “supervisor” page table attribute. However, there are other documented ways of causing page fault behavior on x86 processors [4], for example by clearing the “present” bit orsetting one of the “reserved” bits in a page table entry(PTE). As Intel documents [5], these page faults cause
the virtual to physical address translation process to abort
immediately and are accordingly referred to as terminal faults. Interestingly, Intel claims that terminal faults
behave differently than permission-based page faults at

2. Foreshadow-VMM A malicious guest virtual machine has control over the first address mapping andcan thus trigger terminal faults directly by clearing
the present bit in the guest page table. Since terminal fault behavior skips the host address translation step and immediately passes the guest physical address to the L1 cache, such adversaries cantransiently read any cached physical memory on the3system, including memory belonging to other VMs
or the hypervisor itself.

Dangerously, however, despite the fault’s existence,the L1 data cache still passes the unauthorized data on to
the transient out-of-order execution in case the metadata
present in the PTE entry represents a cached physical address. As with previous transient execution attacks [7, 6],secrets can then be brought from the microarchitecturaltransient execution domain into the architecture, e.g., using a cache-based covert channel [10]. Making things
worse, in case the the OS supports page sizes larger than
4 KB (e.g., 2 MB or 1 GB), the attacker can use the inadvertent mapping to access a memory range of up to thepage size.
We note here that, since all software intrinsicallyshares the same underlying physical address space, inadvertent virtual to physical mappings created by metadata may point to data belonging to the OS kernel, VMM
memory, SGX enclaves, or SMM memory. In the common case where OSs zero out PTEs when releasing
memory via the munmap system call, attackers can access data stored at physical address 0x00.

3. Foreshadow-SGX Finally, as demonstrated in theForeshadow attack [9], adversaries controlling thefinal address translation output can abuse terminal
faults to bypass SGX abort page semantics mechanism when transiently computing on cached enclave secrets. Such adversaries can provoke terminal faults by either clearing the page table present
bit (e.g., via the mprotect system call), or by setting up a malicious memory mapping in an attackercontrolled enclave.

3.3

Attack Impact

The L1 cache is a joint physical resource, shared between
all software running at any privilege level and security
domain on the same physical core. Consequently, theability to transiently compute on L1 data has far reaching consequences. Foreshadow-NG adversaries may extract data that was accessed by prior computation andleft in the cache following a context switch. Such data
may originate from applications, OS kernel, hypervisor,
and VMs time-sharing the core with the adversary. To
make matters worse, modern Intel processors equippedwith HyperThreading technology [4] also share the L1
cache between sibling logical CPU cores. Secrets may
thus leak between sibling logical cores that concurrently
execute software from different security domains.
Therefore, mitigating Foreshadow-NG includes sanitizing PTEs, flushing the L1 cache when crossing protection boundaries, and modifying OS and hypervisor
schedulers to prevent non-trusting VMs or processes
from executing concurrently on sibling logical cores.

4

Experimental Results. We experimentally verified
Foreshadow-OS attacks by using transient execution toread L1-cached data from pages that have the “present”
bit cleared or if have any of 11 reserved bit set in the PTE
on a machine equipped with an Intel i7-6820HQ CPU.

5

Foreshadow-VMM: Exploitingtrolled Page Table Mappings

Con-

While the above Foreshadow-OS variant allows unprivileged adversaries to transiently compute on unauthorized
physical memory locations, they have no direct control
over which exact physical addresses are being accessed.
Foreshadow-type attacks therefore become a lot moredevastating when considering untrusted virtual machinesthat directly control the guest physical address input tothe L1 tag comparison (Figure 1).
According to the architectural specification [4], guest
physical addresses undergo an EPT-based translation
process to find the underlying host physical memory address. Intel’s analysis [3] revealed that a terminal fault
during the initial guest page table walk causes an earlyout condition, such that the guest physical address is directly passed to the L1 tag comparison without first passing the EPT translation stage. Consequently, malicious
virtual machines can control physical address used toaccess the L1 cache dring transient instructions. Morespecifically, an untrusted malicious guest VM can modify a PTE in its own guest page table, pointing to arbitrary guest physical memory. This address never undergoes an EPT translation as is treated by the L1 tagcomparison as if it were a host physical address.

Foreshadow-OS: Exploiting Inadvertent
Page Table Mappings

Whenever the OS kernel decides to swap a virtual memory page from DRAM to persistent storage, it is required
to clear the PTE present bit. According to the processor’s architectural specification [4], however, the kernel
is free to use the remaining bits in a non-present PTE as
desired. The OS may for instance decide to leave thesebits unchanged, zero them out, or use them to store metadata that assists in bringing back the page from disk.
Thus, while unprivileged user space applications haveno direct control over PTEs, the metadata left by the OS
in a page table entry as it unmaps the corresponding virtual page may still point to a valid physical address containing sensitive data. After the kernel clears the present
bit in the corresponding PTE entry, dereferencing the unmapped page from user space will cause a terminal fault.
4

OS’s control over the page table to provoke terminal
faults when dereferencing enclave memory. Analogous to the Foreshadow-VMM transient EPC bypass
above, Foreshadow-SGX essentially early-outs the address translation, passing any cache enclave secrets to thetransient out-of-order execution before the SGX machinery is allowed to replace them with abort page behavior.
Note that our original Foreshadow-SGX [9] attack furthermore proposed an alternative way to provoke terminal fault behavior via EPCM sanity checks when dereferencing a rogue virtual memory mapping from a customized attacker enclave. This Foreshadow-SGX subvariant has been dubbed “Enclave 2 Enclave” (E2E) inIntel’s analysis [5].

Cloud Server
Physical Core

Logical Core 1

Logical Core 2

VictimVM

AttackerVM

L1 CacheL2 Cache
Victim’s memory

Attacker’s memory

Figure 2: Foreshadow-VMM in action. On Intel processors, the L1 cache is shared between virtual machines(VMs) running on the same physical core. By carefully
manipulating her own memory accesses, the attacker VM
can read arbitrary victim VM data stored in the L1 cache.

7

We now analyze the various mitigation techniques proposed by Intel [3]. At a high level, the mitigations include (i) proactively removing secrets from the L1 cache,(ii) preventing inadvertent mappings that can lead to an
address containing secrets, and finally (iii), adjustments
to scheduling algorithms to prevent two distrusting entities from running on sibling cores, which share the L1
cache.

Figure 2 illustrates one scenario where opportunistic
fetching from L1 cache allows a malicious guest VM totransiently steal host physical memory secrets belonging
to another co-resident VM. Note, however, that the attack
is not limited to HyperThreading victims as ForeshadowVMM can extract any secret residing in the L1 data cacheof the physical CPU core (e.g., leftover VMM data aftera hypercall).

6

Mitigations

7.1

Protecting the Kernel and Processes

Attackers mounting Foreshadow-OS rely on existing
mappings in the page table entries. Since the page table permission model can no longer be trusted to sufficiently protect data, the proposed mitigation [5] is toensure there are no unintended mappings. There are twodifferent approaches to achieving this.
First, the operating system may wish to direct any
Foreshadow-OS attack to a special page not containing
any secrets. This approach could be applied for instancewhen a virtual page is not intended to be backed by any
physical memory. Under Linux, for example, the lastlevel page table entries are zero’ed out in such situations.
When during a page table walk the processor reaches a
zero’ed out PTE entry, data located at physical address
0 may be leaked. To mitigate such attacks, Intel proposes [5] to place a zero’ed 4 KB page at that address.
To avoid leaking data through huge (2MB/1GB) pages
from address 0, the Page Size (PS) bit should never be
set in page directory entries (PDE) and page directory
pointer table entries (PDPTE) of non-present pages.
A second approach is to ensure that during a
Foreshadow-OS attack, non-existent physical memory
would be referenced. This is especially valuable when
the operating system wishes to store meta data about
the page that used to be present in memory. For example, operating systems may use this approach to track

Foreshadow-SGX

Intel SGX [4] is a set of x86 processor extensions thatenforce strict isolation and attestation guarantees for secure enclaves that live in the address space of a conventional OS process, without having to trust any of the supporting software — including privileged OS kernel andhypervisor. As illustrated in Figure 1, SGX machinery
performs an additional level of sanity checks after thelegacy address translation process completed, to enforce
strict access control for enclaves and to guard against
direct address remapping attacks [2]. Upon encountering an unauthorized enclave access, SGX machinery ignores writes and replaces the value being read with theabort page dummy value −1. Intel SGX’s unique abort
page semantics mechanism prohibits enclave data frombeing directly extracted through a plain Meltdown [7]style transient execution attack, since they are appliedsilently without raising an exception.
In prior work [9], we demonstrated how adversaries
can abuse microarchitectural L1TF behavior to readcached data from SGX secure enclaves, including fullsealing and attestation keys from Intel’s own architectural enclaves. This work was the first to develop
a novel attack methodology that abuses the untrusted
5

swapped out pages. The maximum number of valid
bits in a physical address is machine specific and denoted as MAXPHYADDR. For 4 KB pages, the number of bits in the PTE representing the physical address
are MAXPHYADDR-12. For example, in machines
which can support at most 236 bytes, MAXPHYADDR= 36. In most systems, the actual physical memory used
is less than the maximum supported by the processor.
Therefore, the OS can choose to reduce the maximum
supported physical memory to MAXPHYADDR −n.
Whenever the OS needs to clear the present bit in a PTE,
it will also set the n upper bits in the physical address.
For instance, if a PTE points to physical address 0x1000, and n = 2, after clearing the present
bit and setting bits 34-35, the PTE will point to
0xc00000000k0x1000 = 0xc00001000. If an attacker
tries to mount Foreshadow-OS, the speculative execution
will try to search for a cache line matching 0xc00001000.
Since the machine in this example have at most 236−2=34
bytes of physical memory, the maximum valid physicaladdress is 0x3ffffffff, which is lower than 0xc00001000.

7.2

cache, ENCLS instructions have been modified to also
perform an L1 flush before returning.
Even with microcode updates in place, enclave secrets
are still present in the L1 cache while the enclave is executing. This is problematic as the L1 cache is shared between logical cores. Our work [9] demonstrates a proofof-concept Foreshadow attack launched from the siblingof the logical core that executes the enclave. We are
yet to replicate this attack with the microcode patches inplace. Consequently, we are unable to confirm whether
in the presence of HyperThreading SGX is still vulnerable to the Foreshadow attack.
Intel added a mitigation for cross logical core attacks.
With the microcode patches in place, different keys arederived when HyperThreading is turned on/off. As aresult enclave data sealed when HyperThreading was
turned off, cannot be unsealed while HyperThreadingis active. Also the attestation mechanism is modified
slightly. Quotes incorporate the status of HyperThreading on the machine the quote was generated on. It is left
to the remote entity verifying the attestation, to decide
whether to trust HyperThreading-enabled systems.
This approach poses challenges to businesses provisioning sensitive data to enclaves running on consumer
devices. Requesting non-expert users to disable HyperThreading in the BIOS, is challenging. In addition, disabling HyperThreading affects the entire platform, notjust SGX enclaves. When Intel announced HyperThreading, the technology was advertised to increase the performance of up to 30%. [8] While actual performance
improvements are application-specific [1], the extent towhich users could be persuaded to disable HyperThreading is yet to be determined..

Protecting the Hypervisor and VMs

Attacks mounted by malicious guest VMs can be prevented by ensuring the L1 cache is free of secret information and by ensuring the VMM never runs concurrently
to an untrusted guest VM on the same physical core (i.e.,
on a sibling core). With new microcode updates, Intel
added a mechanism to actively flush the L1 cache (i.e.,
the new IA32 FLUSH CMD MSR). Hypervisors transfer control to guest VMs by executing a VMENTER instruction. To mitigate Foreshadow-VMM, hypervisors
should flush the L1 cache prior to executing VMENTER,
erasing any potential secrets.
If HyperThreading is enabled, hypervisors in addition
must make sure that no hypervisor thread is running ona sibling core together with an untrusted VM. This mitigation presents a paradigm shift in managing cores. Typically, every logical core is managed as an independent
unit of execution.

7.3

7.4

Protecting SMM Memory

Similarly to the mitigations for securing VMMs and enclaves, SMM memory is protected through L1 cache
flushing upon executing the RSM instruction to leave
the SMM. To prevent a malicious OS from running ona sibling logical core alongside SMM execution, SMM
code can “rendezvous” with all logical cores upon both
entry and exit. Effectively, this policy ensures that nocore is running any non-SMM code. This mitigation requires patching the BIOS, which is responsible for loading SMM code. According to Intel [3], most SMM software performs a “rendezvous” anyway. Thus only small
BIOS modifications are required.

Protecting SGX enclaves

The newly released microcode patch, protects SGX enclaves in two ways: (i) by ensuring no secrets residein the L1 cache when the enclave is not executing and(ii) including the status of HyperThreading during any
key derivation and attestation. The former mitigationis met by flushing the L1 cache upon any enclave exit
event; either through an explicitly EEXIT instruction or
through an Asynchronous Enclave Exit (AEX). As we
identified [9] that OS-level SGX leaf instructions EWB
and ELDU can be abused to bring enclave secrets into L1

8Conclusion

In this paper we analyze the impact of the Foreshadow
attack [9] we discovered and of the Foreshadow-NG attacks, which Intel discovered [5]. The Foreshadow-NG
6attacks are the first attacks that fully escape the virtual
machine sandbox.
We strongly urge users to update their systems to mitigate these attacks, and follow mitigation guidelines published by Intel.

Extracting the keys to the Intel SGX kingdom withtransient out-of-order execution. In Proceedingsof the 27th USENIX Security Symposium. USENIX
Association, August 2018.
[10] Y. Yarom and K. Falkner. Flush+reload: A highresolution, low noise, L3 cache side-channel attack.
In 23rd USENIX Security Symposium, pages 719–
732. USENIX Association, 2014.

References[1] S. Casey. How to determine the effectivenessof hyper-threading technology with an application. https://software.intel.com/enus/articles/how-to-determine-theeffectiveness-of-hyper-threadingtechnology-with-an-application/.
[2] V. Costan and S. Devadas. Intel SGX explained.
Technical report, Computer Science and Artificial
Intelligence Laboratory MIT, 2016. https://eprint.iacr.org/2016/086.pdf.
[3] Intel. Description and mitigation overview for
L1 Terminal Fault.
https://software.
intel.com/security-softwareguidance/software-guidance/l1terminal-fault.
[4] Intel. Intel 64 and IA-32 Architectures Software Developer’s Manual – Combined Volumes, December
2017.
[5] Intel. Intel Analysis of L1 Terminal Fault, August
2018.
[6] P. Kocher, D. Genkin, D. Gruss, W. Haas,
M. Hamburg, M. Lipp, S. Mangard, T. Prescher,
M. Schwarz, and Y. Yarom. Spectre attacks:
Exploiting speculative execution. arXiv preprint
arXiv:1801.01203, 2018.
[7] M. Lipp, M. Schwarz, D. Gruss, T. Prescher,
W. Haas, S. Mangard, P. Kocher, D. Genkin,
Y. Yarom, and M. Hamburg. Meltdown. arXiv
preprint arXiv:1801.01207, 2018.
[8] D. Marr, F. Binns, D. Hill, G. Hinton,
D. Koufaty, J. A. Miller, and M. Upton.
Hyper-threading
technology
architecture
and microarchitecture.
Intel Technology
Journal, 6.
https://web.archive.
org/web/20121019025809/http://www.intel.com/technology/itj/
2002/volume06issue01/vol6iss1_
hyper_threading_technology.pdf.
[9] J. Van Bulck, M. Minkin, O. Weisse, D. Genkin,
B. Kasikci, F. Piessens, M. Silberstein, T. F.
Wenisch, Y. Yarom, and R. Strackx. Foreshadow:
7