Spectre (security vulnerability)
Spectre (security vulnerability)
Main page
205230

Spectre (security vulnerability)

logo
Community Hub0 subscribers
Read side by side
Spectre (security vulnerability)
View on Wikipedia
from Wikipedia

Spectre
A logo created for the vulnerability, featuring a ghost with a branch
CVE identifiersCVE-2017-5753 (Spectre-V1),
CVE-2017-5715 (Spectre-V2)
Date discoveredJanuary 2018; 7 years ago (2018-01)
Affected hardwareAll pre-2019 microprocessors that use branch prediction
WebsiteOfficial website Edit this at Wikidata

Spectre is one of the speculative execution CPU vulnerabilities which involve side-channel attacks. These affect modern microprocessors that perform branch prediction and other forms of speculative execution.[1][2][3] On most processors, the speculative execution resulting from a branch misprediction may leave observable side effects that may reveal private data to attackers. For example, if the pattern of memory accesses performed by such speculative execution depends on private data, the resulting state of the data cache constitutes a side channel through which an attacker may be able to extract information about the private data using a timing attack.[4][5][6]

In addition to vulnerabilities associated with installed applications, JIT engines used for JavaScript were found to be vulnerable. A website can read data stored in the browser for another website, or the browser's memory itself.[7]

Two Common Vulnerabilities and Exposures records related to Spectre, CVE-2017-5753 (bounds check bypass, Spectre-V1, Spectre 1.0) and CVE-2017-5715 (branch target injection, Spectre-V2), have been issued.[8]

In early 2018, Intel reported that it would redesign its CPUs to help protect against the Spectre and related Meltdown vulnerabilities (especially, Spectre variant 2 and Meltdown, but not Spectre variant 1).[9][10][11][12] On 8 October 2018, Intel was reported to have added hardware and firmware mitigations regarding Spectre and Meltdown vulnerabilities to its latest processors.[13]

History

[edit]

Yukiyasu Tsunoo and colleagues from NEC showed how to attack MISTY and DES symmetric key ciphers, in 2002 and 2003 respectively. In 2005, Daniel Bernstein from the University of Illinois, Chicago reported an extraction of an OpenSSL AES key via a cache timing attack, and Colin Percival had a working attack on the OpenSSL RSA key using the Intel processor's cache. In 2013 Yuval Yarom and Katrina Falkner from the University of Adelaide showed how measuring the access time to data lets a nefarious application determine if the information was read from the cache or not. If it was read from the cache the access time would be very short, meaning the data read could contain the private key of encryption algorithms. This technique was used to successfully attack GnuPG, AES and other cryptographic implementations.[14][15][16][17][18][19] In January 2017, Anders Fogh gave a presentation at the Ruhr University Bochum about automatically finding covert channels, especially on processors with a pipeline used by more than one processor core.[20]

Spectre proper was discovered independently by Jann Horn from Google's Project Zero and Paul Kocher in collaboration with Daniel Genkin, Mike Hamburg, Moritz Lipp, and Yuval Yarom.[4][21] It was made public in conjunction with another vulnerability, Meltdown, on 3 January 2018, after the affected hardware vendors had already been made aware of the issue on 1 June 2017.[22] The vulnerability was called Spectre because it was "based on the root cause, speculative execution. As it is not easy to fix, it will haunt us for quite some time."[23]

On 28 January 2018, it was reported that Intel shared news of the Meltdown and Spectre security vulnerabilities with Chinese technology companies before notifying the U.S. government of the flaws.[24]

On 29 January 2018, Microsoft was reported to have released a Windows update that disabled the problematic Intel Microcode fix—which had, in some cases, caused reboots, system instability, and data loss or corruption—issued earlier by Intel for the Spectre Variant 2 attack.[25][26] Woody Leonhard of ComputerWorld expressed a concern about installing the new Microsoft patch.[27]

Since the disclosure of Spectre and Meltdown in January 2018, much research has been done on vulnerabilities related to speculative execution. On 3 May 2018, eight additional Spectre-class flaws provisionally named Spectre-NG by c't (a German computer magazine) were reported affecting Intel and possibly AMD and ARM processors. Intel reported that they were preparing new patches to mitigate these flaws.[28][29][30][31] Affected are all Core i Series processors and Xeon derivates since Nehalem (2010) and Atom-based processors since 2013.[32] Intel postponed their release of microcode updates to 10 July 2018.[33][32]

On 21 May 2018, Intel published information on the first two Spectre-NG class side-channel vulnerabilities CVE-2018-3640 (Rogue System Register Read, Variant 3a) and CVE-2018-3639 (Speculative Store Bypass, Variant 4),[34][35] also referred to as Intel SA-00115 and HP PSR-2018-0074, respectively.

According to Amazon Germany, Cyberus Technology, SYSGO, and Colin Percival (FreeBSD), Intel revealed details on the third Spectre-NG variant CVE-2018-3665 (Lazy FP State Restore, Intel SA-00145) on 13 June 2018.[36][37][38][39] It is also known as Lazy FPU state leak (abbreviated "LazyFP") and "Spectre-NG 3".[38]

On 10 July 2018, Intel revealed details on another Spectre-NG class vulnerability called "Bounds Check Bypass Store" (BCBS), or "Spectre 1.1" (CVE-2018-3693), which was able to write as well as read out of bounds.[40][41][42][43] Another variant named "Spectre 1.2" was mentioned as well.[43]

In late July 2018, researchers at the universities of Saarland and California revealed ret2spec (aka "Spectre v5") and SpectreRSB, new types of code execution vulnerabilities using the return stack buffer (RSB).[44][45][46]

At the end of July 2018, researchers at the Graz University of Technology revealed "NetSpectre", a new type of remote attack similar to Spectre v1, but which does not need attacker-controlled code to be run on the target device.[47][48]

On 8 October 2018, Intel was reported to have added hardware and firmware mitigations regarding Spectre and Meltdown vulnerabilities to its latest processors.[13]

In November 2018, five new variants of the attacks were revealed. Researchers attempted to compromise CPU protection mechanisms using code to exploit the CPU pattern history table, branch target buffer, return stack buffer, and branch history table.[49]

In August 2019, a related speculative execution CPU vulnerability, Spectre SWAPGS (CVE-2019-1125), was reported.[50][51][52]

In July 2020 a team of researchers from TU Kaiserslautern in Germany published a new Spectre variant called "Spectre-STC" (single-threaded contention). This variant makes use of port contention in shared resources and can be applied even in single-threaded cores.[53]

In late April 2021, a related vulnerability was discovered that breaks through the security systems designed to mitigate Spectre through use of the micro-op cache. The vulnerability is known to affect Skylake and later processors from Intel and Zen-based processors from AMD.[54]

In February 2023, a team of researchers at North Carolina State University uncovered a new code execution vulnerability called "Spectre-HD", also known as "Spectre SRV" or "Spectre v6". This vulnerability leverages speculative vectorization with selective replay (SRV) technique showing "Leakage from Higher Dimensional Speculation".[55][56]

Mechanism

[edit]

Instead of a single easy-to-fix vulnerability, the Spectre white paper[1] describes a whole class[57] of potential vulnerabilities. They are all based on exploiting side effects of speculative execution, a common means of hiding memory latency and so speeding up execution in modern microprocessors. In particular, Spectre centers on branch prediction, which is a special case of speculative execution. Unlike the related Meltdown vulnerability disclosed at the same time, Spectre does not rely on a specific feature of a single processor's memory management and protection system, but is instead a more generalized idea.

The starting point of the white paper is that of a side-channel timing attack[58] applied to the branch prediction machinery of modern microprocessors with speculative execution. While at the architectural level documented in processor data books, any results of misprediction are specified to be discarded after the fact, the resulting speculative execution may still leave side effects, like loaded cache lines. These can then affect the so-called non-functional aspects of the computing environment later on. If such side effects – including but not limited to memory access timing – are visible to a malicious program, and can be engineered to depend on sensitive data held by the victim process, then these side effects can result in such data becoming discernible. This can happen despite the formal architecture-level security arrangements working as designed; in this case, lower, microarchitecture-level optimizations to code execution can leak information not essential to the correctness of normal program execution.

The Spectre paper explains the attack in four essential steps:

  1. First, it shows that branch prediction logic in modern processors can be trained to reliably hit or miss based on the internal workings of a malicious program.
  2. It then goes on to show that the subsequent difference between cache hits and misses can be reliably timed, so that what should have been a simple non-functional timing difference can in fact be subverted into a covert channel which extracts information from an unrelated process's inner workings.
  3. Thirdly, the paper synthesizes the results with return-oriented programming exploits and other principles with a simple example program and a JavaScript snippet run under a sandboxing browser; in both cases, the entire address space of the victim process (i.e. the contents of a running program) is shown to be readable by simply exploiting speculative execution of conditional branches in code generated by a stock compiler or the JavaScript machinery present in an existing browser. The basic idea is to search existing code for places where speculation touches upon otherwise inaccessible data, manipulate the processor into a state where speculative execution has to contact that data, and then time the side effect of the processor being faster, if its by-now-prepared prefetch machinery indeed did load a cache line.
  4. Finally, the paper concludes by generalizing the attack to any non-functional state of the victim process. It briefly discusses even such highly non-obvious non-functional effects as bus arbitration latency.

Variants

[edit]

Spectre Variant 1

[edit]

Spectre Variant 1, also called Bounds Check Bypass, is an exploit of CPU speculative execution in conditional branches related to memory access bounds. This occurs because the CPU speculatively accesses memory with specific bounds, such as arrays, leading to a bounds bypass (out-of-bounds index access). This speculative execution happens before the CPU validates the bounds check or reverts after a misprediction occurs, resulting in a side-channel leakage.[59]

This attack is the result of conditional branch misprediction, which causes a vulnerable processor to speculatively access out-of-bounds data before the access is validated and before any exception arises.

Spectre Variant 2

[edit]

Spectre Variant 2, also called Branch Target Injection, is an exploitation of the CPU's speculative execution of indirect branches, unlike Spectre Variant 1, which is related to conditional branches. This vulnerability arises due to misprediction by the indirect branch predictor.

This vulnerability differs from Variant 1 because indirect branches are branches whose targets are unknown at compile time and need to be resolved dynamically. An attacker can poison the Branch Target Buffer (a buffer that stores the history of previously taken branches), causing the indirect branch predictor to mispredict and redirect execution to locations that the program's control flow would never legitimately reach.

Remote exploitation

[edit]

While Spectre is simpler to exploit with a compiled language such as C or C++ by locally executing machine code, it can also be remotely exploited by code hosted on remote malicious web pages, for example interpreted languages like JavaScript, which run locally using a web browser. The scripted malware would then have access to all the memory mapped to the address space of the running browser.[60]

The exploit using remote JavaScript follows a similar flow to that of a local machine code exploit: flush cache → mistrain branch predictor → timed reads (tracking hit / miss).

The clflush instruction (cache-line flush) cannot be used directly from JavaScript, so ensuring it is used requires another approach. There are several automatic cache eviction policies which the CPU may choose, and the attack relies on being able to force that eviction for the exploit to work. It was found that using a second index on the large array, which was kept several iterations behind the first index, would cause the least recently used (LRU) policy to be used. This allows the exploit to effectively clear the cache just by doing incremental reads on a large dataset. The branch predictor would then be mistrained by iterating over a very large dataset using bitwise operations for setting the index to in-range values, and then using an out-of-bounds address for the final iteration. A high-precision timer would then be required in order to determine if a set of reads led to a cache-hit or a cache-miss. While browsers like Chrome, Firefox, and Tor Browser (based on Firefox) have placed restrictions on the resolution of timers (required in Spectre exploit to determine if cache hit/miss), at the time of authoring the white paper, the Spectre author was able to create a high-precision timer using the web worker feature of HTML5.

Careful coding and analysis of the machine code executed by the just-in-time compilation (JIT) compiler was required to ensure the cache-clearing and exploitive reads were not optimized out.

Impact

[edit]

As of 2018, almost every computer system is affected by Spectre, including desktops, laptops, and mobile devices. Specifically, Spectre has been shown to work on Intel, AMD, ARM-based, and IBM processors.[61][62][63] Intel responded to the reported security vulnerabilities with an official statement.[64] AMD originally acknowledged vulnerability to one of the Spectre variants (GPZ variant 1), but stated that vulnerability to another (GPZ variant 2) had not been demonstrated on AMD processors, claiming it posed a "near zero risk of exploitation" due to differences in AMD architecture. In an update nine days later, AMD said that "GPZ Variant 2 ... is applicable to AMD processors" and defined upcoming steps to mitigate the threat. Several sources took AMD's news of the vulnerability to GPZ variant 2 as a change from AMD's prior claim, though AMD maintained that their position had not changed.[65][66][67]

Researchers have indicated that the Spectre vulnerability can possibly affect some Intel, AMD, and ARM processors.[68][69][70][71] Specifically, processors with speculative execution are affected with these vulnerabilities.[72]

ARM has reported that the majority of their processors are not vulnerable, and published a list of the specific processors that are affected by the Spectre vulnerability: Cortex-R7, Cortex-R8, Cortex-A8, Cortex-A9, Cortex-A15, Cortex-A17, Cortex-A57, Cortex-A72, Cortex-A73 and ARM Cortex-A75 cores.[73] Other manufacturers' custom CPU cores implementing the ARM instruction set, such as those found in newer members of the Apple A series processors, have also been reported to be vulnerable.[74] In general, higher-performance CPUs tend to have intensive speculative execution, making them vulnerable to Spectre.[75]

Spectre has the potential of having a greater impact on cloud providers than Meltdown. Whereas Meltdown allows unauthorized applications to read from privileged memory to obtain sensitive data from processes running on the same cloud server, Spectre can allow malicious programs to induce a hypervisor to transmit the data to a guest system running on top of it.[76]

Mitigation

[edit]

Since Spectre represents a whole class of attacks, most likely, there cannot be a single patch for it.[3] While work is already being done to address special cases of the vulnerability, the original website devoted to Spectre and Meltdown states, "As [Spectre] is not easy to fix, it will haunt us for a long time."[4] At the same time, according to Dell: "No 'real-world' exploits of these vulnerabilities [i.e., Meltdown and Spectre] have been reported to date [7 February 2018], though researchers have produced proof-of-concepts."[77][78]

Several procedures to help protect home computers and related devices from the vulnerability have been published.[79][80][81][82] Spectre patches have been reported to significantly slow down performance, especially on older computers; on the eighth generation Core platforms, benchmark performance drops of 2–14 percent have been measured.[83][5][84][85][86] On 18 January 2018, unwanted reboots, even for newer Intel chips, due to Meltdown and Spectre patches, were reported.

In early January 2018, Chris Hoffman of the website HowToGeek suggested that the fix would require "a complete hardware redesign for CPUs across the board" and noted how, once software fixes were released, benchmarks showed and vendors claimed that some users may notice slowdowns on their computers once patched.[87]

As early as 2018, machine learning has been employed to detect attacks in real time.[88] This has led to an arms race where attackers also employ machine learning to thwart machine learning based detectors, and detectors in turn employ Generative Adversarial Networks to adapt detection techniques.[89]

On 4 January 2018, Google detailed a new technique on their security blog called "Retpoline" (a portmanteau of return and trampoline)[90] which can overcome the Spectre vulnerability with a negligible amount of processor overhead. It involves compiler-level steering of indirect branches towards a different target that does not result in a vulnerable speculative out-of-order execution taking place.[91][92] While it was developed for the x86 instruction set, Google engineers believe the technique is transferable to other processors as well.[93]

On 25 January 2018, the current status and possible future considerations in solving the Meltdown and Spectre vulnerabilities were presented.[94]

In March 2018, Intel announced that they had developed hardware fixes for Meltdown and Spectre-V2 only, but not Spectre-V1.[9][10][11] The vulnerabilities were mitigated by a new partitioning system that improves process and privilege-level separation.[12]

On 8 October 2018, Intel is reported to have added hardware and firmware mitigations regarding Spectre and Meltdown vulnerabilities to its Coffee Lake-R processors and onwards.[13]

On 18 October 2018, MIT researchers suggested a new mitigation approach, called DAWG (Dynamically Allocated Way Guard), which may promise better security without compromising performance.[95]

On 16 April 2019, researchers from UC San Diego and University of Virginia proposed Context-Sensitive Fencing, a microcode-based defense mechanism that surgically injects fences into the dynamic execution stream, protecting against a number of Spectre variants at just 8% degradation in performance.[96]

On 26 November 2021, researchers from Texas A&M University and Intel showed that Spectre attack (and other family of transient attacks) cannot be detected by typical antivirus or anti-malware software currently available, before they leak data. Especially, they show that it is easy to generate evasive versions of these attacks to build malware instead of their generic gadgets to bypass current antivirus applications. It was shown that this is due to the fact that these attacks can leak data using transient instructions that never get committed during a very short transient window and so are not visible from architecture layer (software) before leakage, but they are visible in microarchitecture layer (hardware). Additionally, software is limited to monitor four Hardware Performance Counters (HPCs) every 100 ns, which makes it difficult and almost impossible to collect information about malicious activity correlated with these attacks from software using antivirus applications before they can leak data.[88]

On 20 October 2022, researchers from North Carolina State University, UC San Diego and Intel announced that they were able to design the first detection technology that can detect transient attacks before leakage in the microarchitecture layer (hardware). This was accomplished by building the first machine learning accelerator for security, designed to be built in Intel chips. This technology has a fast speed of sampling activity of transient instructions every 1ns and making predictions every 10 nanoseconds, allowing detection of transient attacks such as Spectre and Meltdown before data leakage occurs, and it automatically enables counter measurements in the chip. This technology is also equipped with adversarial training, making it immune to large category of adversarial and evasive versions of Spectre attack.[89]

Linux

[edit]

When Intel announced that Spectre mitigation can be switched on as a "security feature" instead of being an always-on bugfix, Linux creator Linus Torvalds called the patches "complete and utter garbage".[97][98] Ingo Molnár then suggested the use of function tracing machinery in the Linux kernel to fix Spectre without Indirect Branch Restricted Speculation (IBRS) microcode support. This would, as a result, only have a performance impact on processors based on Intel Skylake and newer architecture.[99][100][101] This ftrace and retpoline-based machinery was incorporated into Linux 4.15 of January 2018.[102] The Linux kernel provides a sysfs interface to enumerate the current status of the system regarding Spectre in /sys/devices/system/cpu/vulnerabilities/ [75]

Microsoft Windows

[edit]

On 2 March 2019, Microsoft is reported to have released an important Windows 10 (v1809) software mitigation to the Spectre v2 CPU vulnerability.[103]

Summary of mitigations on Microsoft Windows
Vulnerability CVE Exploit name Public vulnerability name Windows changes Firmware changes Ref(s).
Spectre 2017-5753 Variant 1 Bounds Check Bypass (BCB) Recompiling with a new compiler
Hardened browser to prevent exploit from JavaScript		 No [8]
Spectre 2017-5715 Variant 2 Branch Target Injection (BTI) New CPU instructions eliminating branch speculation Yes [8]
Meltdown 2017-5754 Variant 3 Rogue Data Cache Load (RDCL) Isolate kernel and user mode page tables No [8]
Spectre-NG 2018-3640 Variant 3a Rogue System Register Read (RSRR[104]) Yes [105][34]
Spectre-NG 2018-3639 Variant 4 Speculative Store Bypass (SSB) Yes [105][34]
Spectre-NG 2018-3665 Lazy FP State Restore [38][39]
Spectre-NG 2018-3693 Variant 1.1 Bounds Check Bypass Store (BCBS)
Spectre Variant 1.2 Read-only protection bypass (RPB)
SpectreRSB Return Mispredict
Spectre-HD Speculative Vectorization Exploit (SRV) [56]

Other software

[edit]

Several procedures to help protect home computers and related devices from the vulnerability have been published.[79][80][81][82]

Initial mitigation efforts were not entirely without incident. At first, Spectre patches were reported to significantly slow down performance, especially on older computers. On the eighth generation Core platforms, benchmark performance drops of 2–14 percent were measured.[83] On 18 January 2018, unwanted reboots were reported even for newer Intel chips.[99]

Since exploitation of Spectre through JavaScript embedded in websites is possible,[1] it was planned to include mitigations against the attack by default in Chrome 64. Chrome 63 users could manually mitigate the attack by enabling the site isolation feature (chrome://flags#enable-site-per-process).[106]

As of Firefox 57.0.4, Mozilla was reducing the resolution of JavaScript timers to help prevent timing attacks, with additional work on time-fuzzing techniques planned for future releases.[21][107]

On January 15, 2018, Microsoft introduced mitigation for Spectre in Visual Studio. This can be applied by using the /Qspectre switch. A developer would need to download and install the appropriate libraries using the Visual Studio installer.[108]

Immune hardware

[edit]

See also

[edit]

References

[edit]

Further reading

[edit]
[edit]
Revisions and contributorsEdit on WikipediaRead on Wikipedia

Spectre (security vulnerability)

View on Grokipedia
from Grokipedia
Spectre is a class of hardware security vulnerabilities in modern microprocessors that exploit speculative execution mechanisms to enable attackers to read sensitive data across security boundaries, such as process isolation or kernel memory protections, via side-channel attacks like cache timing.[1] These flaws, first detailed in a 2018 research paper by Paul Kocher and colleagues, target branch prediction and indirect branch handling in CPUs, allowing malicious code to train predictors and leak information through transient instructions that are later discarded but leave detectable side effects.[1] The primary variants, known as Spectre Variant 1 (CVE-2017-5753) and Variant 2 (CVE-2017-5715), were disclosed on January 3, 2018, after coordinated responsible revelation involving researchers from Google Project Zero, University of Graz, and others.[2][3] Variant 1 misuses conditional branch prediction to speculatively execute bounds-check failures, while Variant 2 poisons branch target buffers (BTBs) to redirect indirect branches toward unauthorized memory accesses.[1] Both carry a medium severity rating of CVSS 3.1 base score 5.6, emphasizing their reliance on local access and high attack complexity but potential for high confidentiality impact with scope changes.[2][3] Spectre affects a wide range of processors, including Intel's Core, Xeon, and Atom families from Haswell (2013) onward, AMD's Ryzen and EPYC series, and ARM-based chips in devices from smartphones to cloud servers, impacting billions of systems worldwide.[4] The vulnerability undermines fundamental security assumptions like address space layout randomization (ASLR) and kernel address isolation, potentially exposing passwords, encryption keys, and personal data through attacks like malicious JavaScript in browsers or compromised cloud virtual machines.[5] Mitigations for Spectre require layered approaches, including processor microcode updates to restrict speculative execution, operating system patches like kernel page table isolation (KPTI), and compiler modifications such as retpoline for indirect branches; however, full hardware fixes in newer CPUs like Intel's Ice Lake and beyond reduce but do not eliminate risks, often at a 5-30% performance cost in affected workloads.[4][5] Ongoing research has identified additional variants and bypasses, including the VMScape attack in September 2025 that breaks VM isolation on AMD and Intel processors, underscoring the persistent challenges in securing speculative processor designs.[6]

Background

Speculative Execution

Speculative execution is a core optimization technique in modern processors, where the CPU anticipates future instructions and begins executing them before confirming their necessity, thereby hiding latencies associated with branch resolutions and memory accesses. This approach allows the processor to continue processing without stalling, assuming the prediction is correct; if incorrect, the effects are discarded to maintain architectural correctness.[7][8] In out-of-order processors, speculative execution relies on several key components to function effectively. Branch predictors, such as the Branch Target Buffer (BTB) and Branch History Buffer (BHB), analyze historical patterns to forecast control flow decisions, like the outcome of conditional branches or the target of indirect jumps. The reorder buffer (ROB) plays a crucial role by tracking instructions in their original program order, enabling the commitment of correct speculative results while squashing incorrect ones and restoring the processor state from a saved checkpoint. These elements integrate into the speculative execution pipeline, which decouples instruction dispatch from execution to maximize throughput.[7][8] The technique traces its roots to the mid-1990s, with early implementations in processors like the Intel Pentium Pro, which introduced out-of-order execution and speculative capabilities to the x86 architecture, marking a shift from in-order designs. Over time, it evolved into more sophisticated systems; for instance, contemporary architectures such as Intel Core series employ multi-level predictors with high accuracy rates, while AMD's Zen microarchitectures incorporate advanced neural-inspired branch prediction units to handle complex workloads.[9] This progression has made speculative execution a staple in high-performance computing, adapting to increasing pipeline depths and instruction-level parallelism.[10][8][11] By enabling the processor to perform useful work during potential delays, speculative execution delivers substantial performance benefits, particularly in branch-intensive applications, by reducing pipeline stalls. Overall, it has been instrumental in driving the multi-decade trend of exponential performance improvements in microprocessors.[10][12] However, when predictions fail, the transiently executed instructions can leave behind artifacts, such as modifications to microarchitectural state like cache contents, that persist beyond the rollback process despite not affecting the visible architectural state. These side effects form the basis for broader categories of side-channel attacks that may leverage such information leaks.[7][8]

Side-Channel Attacks

Side-channel attacks are security exploits that infer secret data by observing indirect information leaks from a physical implementation of a system, rather than targeting the core algorithm or software logic directly.[13] These leaks can arise from various physical characteristics, including timing variations, power consumption, electromagnetic emissions, and acoustic signals emitted during computation.[13] Unlike traditional cryptanalytic attacks, side-channel methods exploit implementation details, such as how hardware processes data, to extract sensitive information like cryptographic keys without direct access to the system's internals.[14] Common types of side-channel attacks include timing-based attacks, which measure differences in execution time to deduce data-dependent operations, and cache-timing attacks, which monitor shared processor cache states to infer memory access patterns.[15] Cache-timing techniques, such as Prime+Probe and Flush+Reload, are particularly effective on modern CPUs where multiple processes or virtual machines share hardware resources.[14] In Prime+Probe, an attacker fills (primes) cache sets with its own data, then measures the time to re-access (probe) them after a victim process runs; eviction by the victim indicates access to conflicting addresses.[15] Flush+Reload, conversely, uses processor instructions to evict specific cache lines and reloads them to detect if the victim accessed shared memory pages based on reload latency.[14] Other types encompass electromagnetic side channels, which capture radiated signals from chip activity, and acoustic channels, which analyze sound emissions from varying computational loads.[13] Historical examples illustrate the evolution of side-channel attacks. One early demonstration was Paul Kocher's 1996 timing attack on cryptographic implementations like Diffie-Hellman and RSA, showing how execution time variations could reveal key bits without physical access.[16] In 2005, Daniel Bernstein extended this to cache-timing, attacking an OpenSSL AES implementation on a Pentium III processor by sending repeated network packets and correlating timing distributions of S-box lookups to recover the full 16-byte key.[17] More recently, the 2014 Rowhammer attack highlighted DRAM-based side channels, where repeated row activations induced bit flips in adjacent rows, enabling data corruption and potential information leakage in shared memory environments.[18] In CPU architectures, side-channel attacks gain potency from shared hardware resources like L1, L2, and last-level caches, which are partitioned but not fully isolated between processes or virtual machines.[19] This sharing is especially problematic in multi-tenant cloud environments, where unrelated workloads co-located on the same physical host can leak data across isolation boundaries, such as virtual machine fences, through cache contention.[20] For instance, an attacker in one tenant can infer a victim's encryption keys or user inputs by observing how the victim's memory accesses displace the attacker's probes in the shared cache.[15] In modern CPUs, speculative execution can amplify these leaks by transiently modifying shared resource states, even if the speculation is later discarded.[14] Measurement techniques for cache side channels rely on cycle-accurate timing to distinguish cache hits (fast access, typically under 100 cycles) from misses (slower, involving DRAM fetches, often over 200 cycles).[14] Tools like the Intel rdtsc instruction provide high-resolution timestamps for these measurements, allowing attackers to sample access times repeatedly.[14] A representative example is the Flush+Reload technique, outlined in pseudocode below, which detects victim access to a shared memory line x: 
for i = 1 to N:  // N [measurement](/page/Measurement) iterations
    clflush(x)   // Evict x from all cache levels
    mfence       // Ensure flush completes
    t1 = rdtsc() // Start timestamp
    access(x)    // Reload x
    t2 = rdtsc() // End timestamp
    mfence       // Serialize
    if (t2 - t1 < threshold) then  // e.g., 120 cycles
        victim accessed x  // Hit: fast reload
    else
        no access  // [Miss](/page/Miss): slow reload
This method achieves high signal-to-noise ratios, with reload times differing by factors of 3–6 between hits and misses on Intel processors.[14]

History

Initial Discovery

The Spectre vulnerabilities were independently identified in mid-2017 through experiments conducted by separate research teams exploring side-channel attacks on modern processors. Jann Horn, a researcher at Google Project Zero, uncovered aspects of the issue while investigating speculative execution behaviors, realizing that transient instructions could leak data across security boundaries via timing-based side channels. Concurrently, a team led by Paul Kocher, including Daniel Genkin, Daniel Gruss, Werner Haas, Mike Hamburg, Moritz Lipp, Stefan Mangard, Michael Schwarz, and Yuval Yarom, demonstrated similar exploits during their work on microarchitectural attacks, attributing the core problem to the misuse of speculative execution for unauthorized memory access. These findings highlighted how processor optimizations intended to improve performance could inadvertently enable cross-process or cross-privilege data exfiltration.[1][21] The discoveries built on earlier research into branch prediction and cache side channels but marked a pivotal realization in late 2017 that speculative execution's transient states left detectable artifacts exploitable for information disclosure, even after the speculation was squashed. Researchers at institutions such as the University of Graz (including Gruss, Lipp, Mangard, and Schwarz) and the University of Adelaide (Yarom) contributed key proofs-of-concept showing leaks of up to several kilobytes per second in controlled settings, emphasizing the vulnerability's potential to bypass isolation mechanisms in operating systems. This work was distinct from but contemporaneous with the Meltdown vulnerability, which was separately identified by a team including some of the same Graz researchers.[1][22] Following the initial experiments, the researchers initiated a coordinated responsible disclosure process on June 1, 2017, notifying CPU vendors including Intel, AMD, and ARM, as well as operating system developers like Microsoft, Apple, and Linux distributors, to allow time for mitigations before public release. This effort involved sharing preliminary results under embargo, assigning CVE identifiers (CVE-2017-5753 and CVE-2017-5715), and collaborating on defenses such as barriers to limit speculation across boundaries, all while adhering to Project Zero's 90-day disclosure policy extended due to the issue's complexity. The process ensured that patches for affected systems were prepared in advance, though full hardware fixes would require future designs.[21][22][23] The first public indication of Spectre came on January 3, 2018, when Google Project Zero issued a cryptic tweet referencing "speculative execution vulnerabilities" alongside Jann Horn's detailed blog post on a related issue, breaking the embargo slightly early due to a leak and prompting coordinated announcements from affected parties later that day. This marked the transition from private coordination to widespread awareness, with the full Spectre paper released shortly thereafter to detail the attacks and mitigations.[24][23]

Disclosure and Early Response

The Spectre vulnerability was publicly disclosed on January 3, 2018, through a coordinated effort involving advisories from Intel, Microsoft, and the independent researchers who discovered it.[25] This timing followed months of private collaboration among the parties to prepare mitigations before the announcement, aiming to minimize disruption while alerting affected users. The disclosure highlighted Spectre's potential to enable attackers to read sensitive data across security boundaries via speculative execution flaws in modern processors.[26] The primary technical details were outlined in the seminal paper "Spectre Attacks: Exploiting Speculative Execution" by Paul Kocher and colleagues, published on arXiv.org on the same day as the disclosure.[26] This work, co-authored by researchers from institutions including Google, the University of Michigan, and Graz University of Technology, provided the foundational analysis of how speculative execution could be abused to leak confidential information, such as kernel memory, through side-channel attacks. Related publications from the same researchers further elaborated on exploitation techniques and initial defenses.[1] In response, the industry rapidly deployed emergency software and hardware updates. The Linux kernel community integrated Google's retpoline mitigation—a technique to prevent branch target injection by replacing indirect branches with safe return trampolines—into kernel version 4.15, released shortly after the disclosure.[27] Microsoft issued security updates for Windows on January 3, including kernel isolation enhancements, while both Intel and AMD released microcode firmware updates to processors to enable hardware-assisted mitigations like Indirect Branch Restricted Speculation (IBRS).[28] The announcement triggered significant media attention and immediate market reactions, with Intel's stock price falling 3.4% on January 3, 2018, amid concerns over the vulnerability's broad impact on its processors.[22] Within days, multiple class-action lawsuits were filed against Intel and AMD in U.S. courts, alleging failure to disclose the flaws earlier and seeking compensation for affected consumers and businesses.[29] Early proof-of-concept exploits, detailed in the Kocher et al. paper, demonstrated practical attacks leaking kernel data from user-space processes on unmodified Linux systems, underscoring the urgency of the patches.[1]

Recent Developments

In 2018, researchers introduced NetSpectre, the first fully remote Spectre attack, enabling arbitrary memory reads over a network by combining Spectre principles with access-driven cache attacks on remote servers.[30] That same year, the ZombieLoad vulnerability emerged as a related speculative execution issue, distinct from core Spectre variants but exploiting microarchitectural data sampling to leak data across privilege boundaries, processes, and virtual machines on Intel processors.[31] Also in 2020, a variant known as Spectre-STC (single-threaded contention) was disclosed, leveraging contention in shared CPU resources like execution ports to infer speculative execution outcomes without multi-threading requirements. These developments extended Spectre's reach to remote and single-threaded scenarios, prompting further mitigations in hardware and software. From 2023 to 2024, chipmakers continued addressing evolving threats. Intel issued security advisory INTEL-SA-01247 in 2025, detailing microcode updates to counter potential information disclosure via indirect branch predictors, building on defenses against Spectre Variant 2.[32] AMD, meanwhile, had been aware of new attack methods bypassing existing protections since 2022, as outlined in security bulletin AMD-SB-1040, which highlighted risks to branch predictor isolation on its processors. These updates reflected ongoing efforts to harden speculative execution safeguards amid persistent variant discoveries. In 2025, several significant disclosures underscored Spectre's enduring impact. In September, ETH Zurich researchers unveiled VMScape (CVE-2025-40300), a Spectre branch target injection exploit targeting virtualization environments on AMD Zen architectures (generations 1 through 5) and Intel Coffee Lake processors, allowing guest virtual machines to leak host kernel data across isolation boundaries in Linux kernels.[33] In August, Intel addressed a stream cache isolation flaw (INTEL-SA-01249, CVE-2025-20109) in its processors, where improper compartmentalization could enable privilege escalation through speculative access to cached data.[34] Earlier, in May, researchers identified new branch prediction unit flaws (CVE-2025-24495) in Intel Core Ultra processors, facilitating kernel memory leaks at rates up to 17 KB/s and re-enabling certain Spectre Variant 2 attacks despite prior mitigations.[35] Research trends have increasingly targeted cloud and virtualized environments, where shared hardware amplifies risks; VMScape, for instance, demonstrated practical cross-VM data exfiltration in unpatched Linux setups, highlighting gaps in branch predictor state isolation. As of 2025, class-action lawsuits against Intel over Spectre and related flaws remain active, with a preliminary settlement approval hearing scheduled for March 2026 in ongoing litigation alleging defective processor designs and performance impacts.[36]

Technical Mechanism

Core Exploitation Principles

Modern processors utilize speculative execution to enhance performance by anticipating branch outcomes and proceeding with instruction execution preemptively. When a branch prediction proves incorrect, the results of these speculatively executed instructions—termed transient instructions—are discarded to restore the correct architectural state. Nevertheless, certain microarchitectural side effects, including alterations to cache contents, endure beyond the reversion process and remain observable, providing a vector for information leakage.[26] Spectre attacks leverage this transient execution by manipulating the branch predictor to induce erroneous speculation that accesses protected victim data. The attacker first poisons the predictor through repeated executions of misleading branch patterns, prompting the CPU to speculatively load victim data into the cache during the transient window. Subsequently, the attacker employs a cache-based side-channel technique, such as Flush+Reload, to probe the cache state; timing variations reveal which data was accessed, enabling reconstruction of secrets one bit or byte at a time.[26] The efficiency of leakage in Spectre is quantified by the rate of information recovery, often modeled as bits extracted per probe attempt. For instance, recovering an 8-bit value requires approximately 256 probes, as the attacker systematically tests each possible byte by indexing into an array of pointers and observing which cache line is populated during speculation; this relies on measurable timing disparities, with cache hits occurring in about 44 cycles versus misses in 270 cycles, resulting in a detectable difference of roughly 200 cycles. In practice, this allows extraction of secret data byte by byte, requiring approximately 256 probes to identify the speculatively accessed cache line corresponding to the secret byte value.[26][14] The overarching attack sequence unfolds in three stages: predictor training, speculation triggering, and side-channel extraction. During training, the attacker biases the branch predictor by iteratively directing branches to a desired target. Speculation is then triggered using crafted inputs that exploit the poisoned state, executing a transient gadget that leaks data via unauthorized memory access. Finally, the side channel recovers the data through repeated timing measurements. Pseudocode illustrating predictor poisoning for a conditional branch attack appears below: 
# Training the predictor
for i in 0 to N-1:
    execute_branch_to_valid_target()  # Bias predictor toward valid path

# Triggering misprediction
execute_conditional_branch(victim_dependent_address)  # Leads to speculative leak
This flow manipulates speculation without altering the program's correct execution path.[26] In contrast to Meltdown, which exploits out-of-order execution and deferred exceptions to bypass privilege checks and leak kernel memory primarily on Intel CPUs, Spectre hinges exclusively on branch prediction inaccuracies and requires no elevation of privileges, rendering it effective across Intel, AMD, and ARM architectures through pure microarchitectural manipulation.[26]

Branch Prediction and Transient Execution

Branch prediction is a fundamental technique in modern processors to mitigate the performance penalties associated with control-flow instructions, such as conditional branches. Static branch prediction relies on compile-time heuristics, such as always predicting branches as taken or not taken based on simple rules, without adapting to runtime behavior. In contrast, dynamic branch prediction uses hardware mechanisms to learn from past execution patterns, updating prediction tables based on observed branch outcomes to improve accuracy over time. Common implementations include two-level predictors, which correlate branch outcomes with global or local history registers to distinguish between similar branches in different contexts, achieving higher prediction rates by indexing pattern history tables (PHTs) with a combination of branch address and history bits. Advanced dynamic predictors, such as Intel's TAGE (TAgged GEometric) predictor, extend this by using multiple history lengths and tagged components to capture long-range patterns, often reaching prediction accuracies exceeding 95% in workloads with repetitive control flow. Branch predictors maintain states in structures like history tables and pattern tables, which store recent branch outcomes and targets to inform future predictions. These tables are typically indexed by partial branch addresses or history sequences, leading to aliasing where multiple branches share entries due to limited table sizes relative to the address space.[26] Unprivileged code can indirectly influence these states by executing branches that collide with victim branch entries, training the predictor to favor incorrect paths without direct access to privileged predictor controls.[26] For instance, in TAGE-like predictors, global branch history registers (BHRs) accumulate outcomes from recent branches across processes, allowing transient manipulations that persist and mislead speculation on sensitive code paths. During speculative execution, a transient execution window forms when the processor mispredicts a branch and begins executing instructions along the wrong path, typically spanning 10 to 100 instructions before the misprediction is resolved and the speculative state is squashed. Within this window, microarchitectural effects—such as cache line loads, updates to branch history, or arithmetic computations—occur and leave detectable traces, even though the architectural state (registers and memory) is rolled back upon resolution.[26] The duration of this window depends on factors like the depth of the pipeline, the complexity of the mispredicted branch condition, and the time to fetch and verify correct instructions, enabling attackers to leverage these side effects for information leakage. In Spectre attacks, the CPU cache serves as an efficient oracle to observe transient execution outcomes through techniques like Flush+Reload. This method involves flushing a target memory address from the cache using the clflush instruction, then speculatively accessing it during the transient window, and finally measuring reload time to infer whether the access occurred.[26] Cache hits during probing yield access times under 100 cycles, while misses exceed 200 cycles, allowing reliable distinction via high-resolution timers.[26] Attackers can perform a binary search over possible secret values, probing addresses to map which were speculatively loaded, thereby reconstructing confidential data byte by byte. This logarithmic scaling underscores the efficiency of iterative probes in extracting multi-byte secrets within the constraints of the transient window.

Variants

Variant 1: Bounds Check Bypass

Spectre Variant 1, also known as bounds check bypass and assigned CVE-2017-5753, exploits speculative execution by mis-training the branch predictor to incorrectly speculate past a conditional bounds check, allowing an out-of-bounds memory access to read secret data during transient execution.[1] In this attack, an adversary trains the processor's branch predictor using repeated executions of code paths with valid indices, priming it to assume a branch will be taken even when the condition later evaluates to false for an invalid index.[1] This misprediction leads the processor to speculatively load data from an unauthorized memory location, which would normally be prevented by the bounds check, thereby exposing sensitive information through side channels before the speculation is squashed.[1] A representative proof-of-concept in JavaScript illustrates the vulnerability, particularly in just-in-time (JIT) compiled environments: 
if (x < array1_size) {
    y = array2[array1[x * 4096]];
}
Here, x is a victim-controlled value that may exceed array1_size, causing the conditional branch to fail at runtime.[1] However, if the branch predictor has been mis-trained to expect the branch to be taken (e.g., via prior accesses with valid x values), the processor speculatively executes the array access array2[array1[x * 4096]], potentially indexing into adjacent memory containing secret data.[1] The multiplication by 4096 ensures the index scales to access distinct cache lines, facilitating precise leakage.[1] Transient execution principles enable this bypass, as the speculative load occurs before the branch resolution invalidates it.[1] The leaked data is not directly returned but manifests in the processor's microarchitectural state, specifically the cache.[1] During the speculative execution, the victim data is loaded into a cache line controlled by the attacker, such as through an attacker array.[1] After the speculation is aborted, the attacker recovers the data using a Flush+Reload technique: flushing the cache line and measuring reload time to infer which byte was speculatively accessed, as faster reload times indicate the data's presence.[1] This variant commonly affects code patterns in JIT compilers, such as V8 in Google Chrome, where dynamic code generation optimizes array accesses without sufficient speculation barriers, and in web browsers executing untrusted JavaScript.[1] Exploiting Variant 1 requires local access to the victim system but no elevated privileges, making it feasible in shared environments like multi-tenant clouds or browsers.[1] Demonstrations have shown it can leak 1-2 bytes of secret data per approximately 1,000 attack attempts, depending on hardware and workload.[1]

Variant 2: Branch Target Injection

Spectre Variant 2, also known as Branch Target Injection (CVE-2017-5715), exploits the branch predictor's indirect branch prediction mechanisms to hijack speculative execution paths and access sensitive data through side channels.[1] In this variant, attackers manipulate the processor's prediction of indirect branch targets, such as jumps or calls, to speculatively execute unintended code sequences that leak secrets.[1] The core attack vector involves poisoning the Branch Target Buffer (BTB) or Return Stack Buffer (RSB) to redirect speculative execution to attacker-controlled "gadgets"—short code snippets that access victim data.[1] Attackers first flush the relevant buffer entries using techniques like cache flushes or timed instruction sequences, then retrain the predictor by executing a series of branches that associate a victim address with a malicious target.[1] When the victim code triggers an indirect branch, the poisoned predictor speculatively jumps to the gadget, which loads secret data into a cache or other observable state before the misprediction is resolved and the execution is rolled back.[1] A fundamental hardware flaw enabling this attack is the sharing of branch prediction structures, such as the BTB and RSB, across privilege levels within the same core, allowing user-mode code to influence kernel-mode predictions.[1] This cross-privilege sharing, designed for performance, permits unprivileged attackers to poison predictors used by higher-privilege code, facilitating leaks from kernel memory to user space.[1] The vulnerability affects processors where these structures are not isolated between security domains, a common design in modern x86 and ARM CPUs.[1] An illustrative example involves a JavaScript-based attack in a web browser, where an attacker flushes the RSB using timed return instructions to manipulate prediction for a subsequent indirect call, enabling speculation that loads victim kernel data into a detectable side channel.[1] Demonstrated in environments like Google Chrome, this approach poisons the RSB by executing a sequence of calls and returns under attacker control, then triggers a victim indirect branch (e.g., in browser or OS code) to speculatively execute a gadget accessing protected memory.[1] Proof-of-concept (PoC) implementations leverage return-oriented programming (ROP)-like chains during the speculative window to construct data extraction sequences.[1] For instance, a gadget such as an arithmetic instruction loading from a victim-controlled address (e.g., "adc edi, dword ptr [ebx + edx + 13BE13BDh]") is speculatively executed to index into secret data, followed by a side-channel probe like Flush+Reload on the cache.[1] These PoCs achieve high poisoning success rates, such as 99.7% on Intel Haswell processors, by mimicking the victim's branch history patterns.[1] Leakage rates via cache side channels in controlled environments reach up to approximately 4 KB/s, as demonstrated in evaluations bypassing partial mitigations on modern Intel CPUs.[37] Earlier PoCs reported lower rates, such as 41 bytes/s in Windows user-space attacks or 1.8 KB/s in KVM hypervisor scenarios, highlighting the potential for scalable extraction once poisoning is established.[1] An early software countermeasure, retpoline, fences indirect branches by replacing them with sequences using direct returns instead of jumps, preventing BTB poisoning while preserving speculation on predictable paths.[1] Introduced by Google, retpoline mitigates Variant 2 by avoiding reliance on the BTB for indirect control flow, though it incurs performance overhead from reduced prediction accuracy.[1]

Advanced and Remote Variants

Advanced variants of the Spectre vulnerability extend the core exploitation techniques of Variants 1 and 2 to more sophisticated scenarios, including remote access and virtualization environments. These developments, emerging from 2018 onward, demonstrate the evolving nature of transient execution attacks by targeting additional processor components such as return stacks and translation lookaside buffers (TLBs). NetSpectre, disclosed in 2018, represents the first fully remote implementation of a Spectre Variant 1 attack, enabling data leakage over a network without executing code on the victim machine. By sending crafted network packets to poison the victim's branch predictor, attackers can induce speculative out-of-bounds memory access, with data exfiltrated via cache side channels. In remote scenarios, this achieves leakage rates of approximately 60 bits per hour using an AVX-based covert channel, or 15 bits per hour using cache-based methods, marking a significant step toward practical network-based exploitation.[30] Spectre Variant 1.1, identified in 2018, refines the bounds check bypass mechanism by leveraging speculative stores to create buffer overflows during transient execution. This sub-variant, assigned CVE-2018-3693, allows attackers to speculatively write to unauthorized memory locations, facilitating information disclosure on affected Intel processors. Complementing this, Spectre Variant 1.2 exploits lazy page table entry (PTE) enforcement, enabling speculative access to kernel memory through manipulated translation structures. A related technique, TLBleed (2018), targets TLB timing side channels to leak page table contents, achieving up to 98.6% accuracy in reconstructing cryptographic keys like RSA private keys on Intel CPUs.[38][39] Ret2spec, also from 2018, introduces attacks exploiting return stack buffers (RSBs) in modern CPUs to hijack speculative control flow at returns. By manipulating the RSB through indirect branches or interrupts, attackers can redirect speculation to gadgets that leak cross-process or kernel data, providing capabilities akin to original Spectre variants but focused on return instructions. This has been shown to work across Intel, AMD, and ARM architectures, underscoring persistent risks in return prediction mechanisms.[40] In virtualization contexts, VMScape (CVE-2025-40300), disclosed in 2025, abuses VM exits to perform cross-VM branch target injection on AMD and Intel processors. This attack poisons the host's branch predictor from a malicious guest, enabling leakage of hypervisor secrets like encryption keys in Linux KVM environments on AMD Zen 1-5 and select Intel CPUs, despite partial mitigations like eIBRS. Demonstrated end-to-end on QEMU, it highlights gaps in cloud isolation for speculative state sharing.[33] Recent 2020s discoveries include CVE-2025-24495, a 2025 Intel flaw in Lion Cove cores (Lunar Lake and Arrow Lake processors) that undermines domain isolation in branch predictors. This vulnerability re-enables Spectre Variant 2 attacks, allowing privilege escalation and kernel memory leaks at rates up to 17 KB/s through speculative execution, including exploitation of stream caches for targeted data extraction.[41] Another 2025 development is Branch Privilege Injection (BPI), presented at USENIX Security 2025 by ETH Zurich researchers, which compromises Spectre Variant 2 hardware mitigations on Intel processors. By exploiting branch predictor race conditions (BPRC), BPI allows unprivileged attackers to inject arbitrary kernel-privileged branch predictions, bypassing protections like Indirect Branch Restricted Speculation (IBRS) and Single Thread Indirect Branch Predictors (STIBP). This re-enables full branch target injection attacks, potentially leaking kernel memory in shared environments such as clouds. Affected CPUs include those from Coffee Lake (2018) onward with post-2018 mitigations; Intel released microcode updates in May 2025.[42] Remote feasibility of these advanced variants remains constrained but viable in cloud settings, such as AWS, where low-bandwidth leaks of around 15-60 bits per hour can occur over shared networks via predictor poisoning, posing risks to multi-tenant environments despite performance overheads.[30]

Affected Systems and Impact

Hardware Affected

The Spectre family of vulnerabilities affects virtually all modern CPUs that employ speculative execution, a performance optimization technique introduced in processors around 2010 and widely adopted thereafter. No hardware architecture achieves full immunity without accompanying software or firmware mitigations, as the core issue stems from transient execution during branch prediction. This encompasses x86, ARM, and other instruction set architectures relying on out-of-order execution and caching mechanisms.[21]

Intel Processors

All Intel Core i-series processors from the 6th generation (Skylake architecture, released in 2015) and subsequent generations are vulnerable to various Spectre variants, including bounds check bypass (Variant 1) and branch target injection (Variant 2). This includes 7th generation (Kaby Lake), 8th and 9th generations (Coffee Lake), 10th and 11th generations (Comet Lake and Rocket Lake), and 12th generation (Alder Lake, 2021) onward. Coffee Lake processors are specifically susceptible to the 2025 VMScape attack, a Spectre-based transient execution exploit that enables virtual machine escapes by leveraging incomplete branch predictor isolation. Alder Lake features partial hardware mitigations, such as enhanced indirect branch predictors, but remains vulnerable to advanced Spectre attacks like Branch Privilege Injection disclosed in 2025, which bypasses enhanced Indirect Branch Restricted Speculation (eIBRS) protections. Intel Xeon Scalable processors, including those based on Skylake-SP, Cascade Lake, and later generations like Sapphire Rapids, are also affected across the Spectre family; a 2025 stream cache isolation flaw (CVE-2025-20109) further exposes these server-oriented chips to data inference via improper cache partitioning.[4][43][44][34]

AMD Processors

AMD Ryzen processors based on Zen 1 (2017, Summit Ridge), Zen 2 (2019, Rome), and Zen 3 (2020, Milan) architectures are fully susceptible to core Spectre exploits due to their speculative execution designs. Zen 4 (2022, Raphael) incorporates hardware fences like Indirect Branch Control to mitigate branch target injection, yet it remains vulnerable to novel 2025 attacks such as VMScape, which exploits cross-VM branch predictor pollution for data leakage. Zen 5 (2024, Granite Ridge) shares similar exposure to these recent transient execution primitives.[43]

ARM Processors

ARM Cortex-A series processors, particularly from Cortex-A75 (2018) and later, including A76, A77, A78, A710, A715, and X-series (X1 through X4), are affected by Spectre variants such as Variant 1, Variant 2, and Spectre-BHB (branch history buffer injection). Earlier models like Cortex-A57, A72, and A73 also exhibit vulnerabilities, with mitigations varying by revision (e.g., Cortex-A75 revisions prior to r3p0 are more broadly exposed). Apple's M-series processors (M1 through M4), built on custom ARMv8 designs, are partially mitigated by Pointer Authentication Codes (PAC) for control-flow integrity but remain leak-prone to Spectre-style attacks, including out-of-place Variant 1 mistraining as demonstrated in 2025 research and earlier demonstrations leaking up to 1500 bytes per second via cross-core channels.[45][46][47]

Other Architectures

IBM Power processors, including Power8, Power9, and later generations, are vulnerable to Spectre due to their speculative execution pipelines, with confirmed impacts on systems running IBM i and AIX. RISC-V implementations employing out-of-order execution, such as the Berkeley Out-of-Order Machine (BOOM), are susceptible to transient execution attacks analogous to Spectre, as verified through replication studies on open-source cores.[48][49][50]

Security and Performance Implications

The Spectre vulnerability poses significant security risks, particularly in multi-tenant cloud environments where it enables cross-virtual machine (VM) data leaks through speculative execution side channels. In such scenarios, attackers can exfiltrate sensitive data at rates of approximately 5 KB/s on Intel Haswell processors, allowing the potential theft of cryptographic keys or other confidential information from adjacent VMs.[1] This undermines the isolation guarantees of virtualization platforms like KVM/QEMU, as demonstrated by the 2025 VMScape attack (CVE-2025-40300), which exploits incomplete branch predictor isolation to leak host memory at 154 B/s on AMD Zen 5 CPUs without requiring host modifications.[43] Browser sandboxes are also vulnerable to Spectre exploits, enabling malicious JavaScript code to bypass isolation and steal user data such as passwords from cross-site contexts. For instance, proof-of-concept attacks in JavaScript engines like those in Google Chrome have shown practical data leakage, confirming the feasibility of remote exploitation via web browsers.[51] In attack scenarios, malware embedded in JavaScript can leverage Spectre Variant 1 to bypass bounds checks and extract passwords or session tokens from memory.[51] Similarly, in multi-tenant servers, Spectre facilitates kernel data exposure, where user-space code speculatively accesses privileged memory, leaking sensitive kernel structures at rates up to 2 KB/s on Intel Haswell Xeon systems via mechanisms like the eBPF JIT compiler.[23] Mitigating Spectre introduces notable performance overheads, with Retpoline—a software technique to thwart indirect branch speculation—causing 20-30% slowdowns in CPU-bound workloads involving frequent branches, such as database queries on Intel Xeon E5 systems.[52] Full deployment of hardware barriers like Indirect Branch Restricted Speculation (IBRS) and Indirect Branch Predictor Barrier (IBPB) can exacerbate this, leading to up to 25-53% overhead in syscall-heavy code paths due to speculation halts during context switches.[53] The economic ramifications of Spectre have been substantial, with global mitigation efforts estimated to cost tens of billions annually in hardware updates, software patches, and performance optimizations across affected devices.[54] The 2018 disclosure triggered immediate market reactions, including a 3-4% drop in Intel's stock price amid investor concerns over liability and remediation expenses.[55] By 2025, developments like VMScape have heightened cloud provider liabilities, as breaches of VM isolation could expose infrastructure secrets to malicious tenants, amplifying risks for state-sponsored actors targeting persistent, low-detection exfiltration in shared environments.[43]

Mitigation Strategies

Software and Firmware Mitigations

Software mitigations for Spectre primarily target the exploitation of branch prediction and speculative execution by inserting barriers or altering code patterns to prevent transient instructions from accessing unauthorized data. These techniques, developed shortly after the vulnerability's disclosure in 2018, focus on software-level interventions that do not rely on hardware changes, though they often complement firmware updates. Retpoline, introduced by Google, exemplifies such an approach by replacing indirect branches with sequences that avoid speculative poisoning of the branch target buffer (BTB).[56] Retpoline mitigates Spectre Variant 2 (branch target injection) by converting indirect calls and jumps into a trampoline sequence involving a direct call to a gadget that executes a loop until the target address is loaded into a register, followed by an indirect jump; this prevents the processor from speculatively following poisoned entries in the BTB or return stack buffer (RSB). The technique uses serializing instructions like LFENCE to ensure speculation halts until the branch resolves correctly. On Intel Xeon processors, Retpoline introduces a performance overhead of approximately 3-5% in typical workloads, though this can vary based on indirect branch frequency. Intel has endorsed and detailed Retpoline as a key software construct for Variant 2 protection.[56][27] Speculation barriers provide another foundational software defense by explicitly halting speculative execution at critical points, such as after bounds checks in Variant 1 attacks or before indirect branches in Variant 2. The LFENCE instruction serves as a low-latency serializing barrier on Intel processors, ensuring prior instructions complete before speculation resumes, thereby blocking transient access to out-of-bounds data. Similarly, STIBP (Single Thread Indirect Branch Predictors) prevents cross-thread leakage by isolating branch predictors between hyperthreads, mitigating scenarios where one thread poisons predictions for another. On AMD processors, equivalent barriers like LFENCE are recommended to control speculation around bounds checks and indirect branches. These instructions are inserted manually or via compiler options to enforce isolation without full serialization.[8][1][57] Firmware updates, particularly microcode patches, enhance these software mitigations by adjusting processor behavior at a low level, such as improving BTB isolation to reduce poisoning risks from indirect branches. Intel has released iterative microcode updates since 2018, covering processors from Skylake onward, to strengthen defenses against Variants 1 and 2 by enhancing speculation controls and predictor flushing. For AMD processors, protections for the RSB have evolved from 2022 through 2025, including mechanisms to underflow or refill the buffer on context switches, preventing speculative misuse of return addresses across security domains. These firmware changes are delivered via BIOS or OS updates and are essential for enabling software techniques like Retpoline without excessive overhead.[4][58] Compiler modifications automate the insertion of these mitigations, making them accessible without manual code changes. In GCC, flags like -mindirect-branch=thunk and -mfunction-return=thunk generate Retpoline sequences for indirect branches and returns, respectively, to counter branch target injection. Clang/LLVM supports similar thunk-based transformations through options like -mfunction-return=thunk, ensuring compatibility with Spectre defenses. Additionally, enhancements to Address Space Layout Randomization (ASLR) in compilers randomize code and data layouts more finely, increasing the entropy of potential targets and complicating speculative leakage paths. These compiler-level interventions integrate into build processes, with operating systems applying them broadly to kernel and user-space code.[59][60][25] In May 2025, Intel issued microcode update INTEL-SA-01247 to address vulnerabilities in indirect branch predictors that could undermine Spectre Variant 2 mitigations, specifically targeting branch privilege injection exploits discovered by ETH Zurich researchers; this update strengthens BTB and RSB isolation on affected Raptor Lake processors via enhanced speculation barriers.[32][44]

Operating System Implementations

The Linux kernel introduced initial mitigations for Spectre vulnerabilities starting with version 4.15 in early 2018, incorporating Page Table Isolation (PTI) to address related Meltdown issues and retpoline to mitigate Variant 1 and Variant 2 by replacing indirect branches with safer alternatives. These patches were backported to earlier stable kernels, enabling administrators to configure protections via kernel parameters like nospec and spec_store_bypass_disable. In 2025, Linux addressed the VMScape variant (CVE-2025-40300), a Spectre v2 extension targeting virtualization environments, through KVM updates in stable kernels 6.6.45, 6.10.5, and later; these include stricter VM exit checks and enhanced branch predictor isolation to prevent guest-to-host userspace leaks in QEMU/KVM setups.[61][62][63] Microsoft Windows implemented Spectre mitigations via the Speculation Control API in January 2018, allowing developers and administrators to enable protections against Variant 1 and Variant 2 through Windows updates and registry settings.[64] For Windows 10 and later versions, these mitigations became mandatory with cumulative updates starting in 2018, integrating kernel-level barriers and hypervisor protections for virtualized environments. In 2025, Windows incorporated microcode updates to address stream cache flaws (CVE-2025-20109) in Intel processors, which could enable privilege escalation via speculative execution side channels; these were delivered automatically through Windows Update for supported hardware.[44][65] Apple's XNU kernel in macOS and iOS adopted Pointer Authentication Codes (PAC) starting with iOS 13 and macOS Catalina in 2019, providing hardware-enforced pointer integrity on ARM-based devices to reduce the impact of Spectre Variant 2 by validating indirect branch targets and mitigating control-flow hijacks.[66] This approach complements earlier software barriers introduced in iOS 11.2 and macOS 10.13.2 in late 2017.[66] Android, leveraging the Linux kernel, applies Spectre mitigations through kernel updates aligned with AOSP releases since 2018, with SELinux enhancements in Android 9 (2018) and later enforcing stricter mandatory access controls to limit side-channel exploitation in multi-process environments.[67] FreeBSD implemented indirect branch tracking mitigations for Spectre Variant 2 via Indirect Branch Restricted Speculation (IBRS) in kernel updates from March 2018, with ongoing support for enhanced branch predictor controls in versions 13.0 and later to handle advanced variants.[68] Deployment of these OS-level mitigations faces challenges, including the need for coordinated auto-updates versus manual firmware flashing for microcode patches, as incomplete coverage can leave systems vulnerable. Performance overhead varies, with Linux PTI adding approximately 10% latency to syscalls on affected Intel hardware, though optimizations in recent kernels have reduced this impact.[62]

Hardware-Based Protections

Hardware-based protections against Spectre vulnerabilities primarily involve modifications to CPU microarchitectures to limit the scope of speculative execution and isolate prediction mechanisms, thereby reducing the potential for branch target injection and related attacks.[8] One key approach targets indirect branch predictors, which can be poisoned to redirect speculation toward malicious code paths. Intel introduced Single Thread Indirect Branch Predictors (STIBP) in 2018, which isolates indirect branch predictions between hyperthreads on the same core, preventing cross-thread control of speculation while allowing intra-thread predictions to proceed.[8] This feature, enabled via the IA32_SPEC_CTRL MSR, complements Indirect Branch Restricted Speculation (IBRS) by addressing sibling thread influences without requiring full serialization.[8] Similarly, AMD enhanced its IBRS implementation in 2019 with Zen 2 processors, introducing an "always-on" mode that provides persistent protection against indirect branch speculation poisoning across privilege levels, minimizing the need for frequent software toggling.[69] These enhancements restrict speculation using prior branch histories only within the same privilege domain, effectively blocking attacks like Spectre Variant 2.[70] Subsequent architectures incorporated further refinements to return stack buffers (RSB) and speculation controls. Intel's Ice Lake processors, released in 2019, improved RSB handling through hardware-supported stuffing techniques, where sequences of CALL instructions with non-zero displacements prevent RSB underflow and limit return address mis-speculation to safe targets during context switches.[8] This mitigates Spectre attacks exploiting return-oriented speculation by ensuring the RSB remains populated with valid entries, reducing leakage risks without disabling speculation entirely.[8] In parallel, ARM's v8.5-A architecture, introduced in 2018, added a Speculation Barrier (SB) instruction that halts speculative execution until prior instructions are resolved, blocking branch target injection by enforcing serial execution at critical points and preventing data leaks via side channels.[45] This barrier is particularly effective in cores like Cortex-A710, where it integrates with branch history buffer mitigations to clear speculative state.[45] Some modern designs offer partial resistance but remain susceptible to evolving threats. Apple's M-series chips, starting with the M1 in 2020, feature hardened speculative execution mechanisms that limit transient state leakage, yet they are vulnerable to novel attacks like SLAP and FLOP disclosed in 2025, which exploit side channels in web browsers to extract sensitive data.[66][71] Likewise, RISC-V implementations support optional speculation barriers, such as fence instructions that selectively restrict out-of-order execution to protect against Spectre gadgets, though adoption varies by core design and requires explicit hardware enablement.[72] Despite these advances, no contemporary CPU achieves full immunity to Spectre without performance trade-offs; as of 2025, Intel and AMD processors, including latest generations, still rely on complementary software aids to address persistent speculative execution flaws like VMScape, which breaches virtual machine isolation.[6][73] Looking ahead, research proposes deeper architectural shifts, such as mode-specific branch predictors that segregate prediction tables by privilege level to prevent cross-domain poisoning, as explored in analyses of branch privilege injection vulnerabilities.[74] Additionally, concepts like transient-execution firewalls aim to insert hardware-enforced isolation layers that dynamically quarantine speculative paths, limiting their access to sensitive state while preserving overall performance, though these remain in the proposal stage without widespread implementation.[75]

Ongoing Research and Future Outlook

New Discoveries

In 2025, researchers at ETH Zurich unveiled VMScape, a novel extension of the Spectre branch target injection (BTI) vulnerability that compromises hypervisor isolation in cloud environments. This attack, tracked as CVE-2025-40300, enables a malicious guest virtual machine to leak data from the host system by exploiting incomplete branch predictor isolation on AMD and Intel CPUs, marking the first end-to-end Spectre-based exploit across VM boundaries.[43] Demonstrations showed successful data exfiltration in setups using KVM/QEMU and VMware, highlighting persistent gaps in speculative execution safeguards despite prior mitigations.[76] Concurrent discoveries included new Intel CPU flaws reported in May 2025, such as CVE-2025-24495, which leverage cache stream mechanisms to enable Spectre-style memory leaks at rates up to 17 KB/s from kernel space. These vulnerabilities, identified by ETH Zurich and VUSec researchers, affect modern Intel processors and bypass existing domain isolation in branch predictors, allowing cross-privilege data extraction.[35] Initial discussions on platforms like Hacker News amplified awareness of these cache-based transients, underscoring their potential in multi-tenant systems.[77] Advancements in research tools have facilitated deeper auditing of speculative behaviors. The KLEE-SPECTRE framework uses symbolic execution to detect information leakage through speculative cache attacks by analyzing binary programs for predictor-dependent side channels.[78] Complementing this, efforts in formal verification, such as the SpecTerminator project, classify instructions by their impact on microarchitectural states to prove security against speculative side channels on RISC-V architectures, enabling hardware-enforced barriers.[79] These tools have been instrumental in validating combined Spectre variants through symbolic execution and semantic proofs.[80] AI-accelerated vulnerability discovery remains nascent, with machine learning models potentially aiding in identifying speculative execution flaws, though practical implementations for exploit generation are limited by training data constraints.[81] Community-driven initiatives have proliferated open-source proofs-of-concept (PoCs) on GitHub, such as SpectreRewind implementations that demonstrate rewind-based transients, fostering reproducible testing across processor generations.[82] At conferences like USENIX Security 2025, papers introduced primitives like Spectre-BSE and Spectre-BHS, exploiting branch history inaccuracies for kernel leaks at high rates, alongside pre-silicon detection methods for transient data leaks.[83][84] These contributions emphasize evolving offensive techniques in eBPF and cross-privilege scenarios.[74] In November 2025, Intel's Linear Address Space Separation (LASS) feature was upstreamed into Linux kernel 6.19, providing mitigation against Spectre-like attacks such as Leaky Address Masking (LAM) by enhancing address space isolation in speculative execution.[85] Significant knowledge gaps persist, particularly in non-x86 architectures, with limited empirical testing of speculation vulnerabilities on GPUs; while Intel iGPUs support Spectre mitigations, Ubuntu's 2025 decision to disable them for performance gains revealed no known real-world GPU exploits, but highlighted unverified risks in parallel execution pipelines.[86] This scarcity of GPU-focused studies underscores broader challenges in auditing diverse hardware ecosystems.[87]

Evolving Defenses

As the understanding of Spectre vulnerabilities deepened, advanced mitigations have increasingly relied on hardware-software co-design to enhance protection without excessive performance penalties. These updates complement software techniques like speculation fence insertion, where formal verification methods ensure barriers are placed to block transient execution paths, as explored in hardware-software co-design frameworks that address leakage patterns unmitigable by fences alone.[88] Similarly, May 2025 microcode revisions further strengthened Spectre v2 defenses by enhancing branch prediction isolation in response to newly identified compromise vectors.[44] Policy responses have evolved to enforce systemic accountability for chip security. The European Union's Cyber Resilience Act, adopted in 2024 and entering full force by 2027, mandates security-by-design principles for hardware products with digital elements, requiring manufacturers to assess and mitigate vulnerabilities like those in speculative execution throughout the product lifecycle.[89] This includes obligations for vulnerability disclosure and patching, directly addressing Spectre-class risks in semiconductors. Complementing this, the EU Chips Act of 2023 promotes certification standards for trusted and secure chips, aiming to reduce supply chain dependencies while ensuring resilience against side-channel attacks.[90] In parallel, major cloud providers have adopted stricter isolation standards; for example, following 2025 disclosures of branch target injection exploits in virtualized environments, platforms like AWS and Google Cloud enabled enhanced KVM-QEMU mitigations to partition branch predictor states between guests and hosts.[91][92] Research directions emphasize verifiable speculation mechanisms to future-proof systems. The DAWG framework, proposed in 2018 and influential in subsequent designs, uses dynamic cache partitioning tied to protection domains to prevent timing attacks during speculative execution, ensuring non-interference by sanitizing shared microarchitectural states with minimal hardware modifications.[93] Building on this, efforts like the PROSPECT model provide formal proofs for secure speculation under constant-time policies, enabling processors to speculate safely without leaking secrets across domains.[94] For secure enclaves such as Intel SGX, mitigations include restricting speculative paths in enclave code—effectively operating in low-speculation modes—through techniques like HyperRace, which detect and nullify transient executions without depending on vendor microcode updates.[95] Key challenges persist in balancing security and performance while managing supply chain complexities. Advanced mitigations target overheads below 5%, with recent branch predictor isolation patches imposing only 1% slowdown on compute-intensive cloud workloads, though emulated environments may see up to 10%.[96][6] Supply chain patching remains arduous, as the Cyber Resilience Act requires coordinated updates across global vendors, yet incomplete adoption risks persistent exposure.[97] Looking ahead, enhanced predictor isolation could yield "Spectre-resistant" CPUs by 2030, with ongoing refinements to branch prediction units—such as domain-specific predictors—addressing current gaps in virtualization, as demonstrated by 2025 analyses of incomplete isolation.[98] However, the arms race continues, as new transient execution flaws drive iterative defenses in an evolving threat landscape.

References

  1. [PDF] Exploiting Speculative Execution - Spectre Attacks
  2. NVD - CVE-2017-5753
  3. NVD - CVE-2017-5715
  4. Affected Processors: Transient Execution Attacks & Related Security...
  5. Meltdown and Spectre Side-Channel Vulnerability Guidance | CISA
  6. https://arxiv.org/pdf/1801.01203.pdf
  7. Hardware Features and Behaviors Related to Speculative Execution
  8. How the Spectre and Meltdown Hacks Really Worked - IEEE Spectrum
  9. AMD Returns To 1996 With Zen 5's Two-Block Ahead Branch Predictor
  10. Spectre Attacks: Exploiting Speculative Execution
  11. Side-Channel Attack - Glossary | CSRC
  12. [PDF] FLUSH+RELOAD: A High Resolution, Low Noise, L3 Cache Side ...
  13. [PDF] Cache Attacks and Countermeasures: the Case of AES 2005-08-14
  14. [PDF] Side-Channel Attacks: Ten Years After Its Publication and the ...
  15. [PDF] Cache-timing attacks on AES
  16. A Comprehensive Survey of Side-Channel Attacks on Memory - arXiv
  17. Side Channels in Multi-Tenant Environments - ACM Digital Library
  18. [PDF] Cross-Tenant Side-Channel Attacks in PaaS Clouds
  19. Meltdown and Spectre
  20. Meltdown and Spectre: 'worst ever' CPU bugs affect virtually all ...
  21. Reading privileged memory with a side-channel - Google Project Zero
  22. How the industry-breaking Spectre bug stayed secret for seven months
  23. Mitigating speculative execution side channel hardware vulnerabilities
  24. [1801.01203] Spectre Attacks: Exploiting Speculative Execution - arXiv
  25. [PDF] Retpoline: A Branch Target Injection Mitigation - Intel
  26. KVA Shadow: Mitigating Meltdown on Windows - Microsoft
  27. Intel facing class-action lawsuits over Meltdown and Spectre bugs
  28. [1807.10535] NetSpectre: Read Arbitrary Memory over Network - arXiv
  29. ZombieLoad Attack
  30. INTEL-SA-01247
  31. VMScape: Exposing and Exploiting Incomplete Branch Predictor ...
  32. INTEL-SA-01249
  33. Researchers Expose New Intel CPU Flaws Enabling Memory Leaks ...
  34. Intel CPU Security Flaw – Settlement Details - Talli Insights
  35. [PDF] Inspecting the Residual Attack Surface of Cross-privilege Spectre v2
  36. New Spectre 1.1 and Spectre 1.2 CPU Flaws Disclosed
  37. [PDF] Defeating Cache Side-channel Protections with TLB Attacks - vusec
  38. ret2spec: Speculative Execution Using Return Stack Buffers - arXiv
  39. Training Solo - vusec
  40. [PDF] VMSCAPE: Exposing and Exploiting Incomplete Branch Predictor ...
  41. INTEL-2025-05-13-001-BranchPrivilegeInjection
  42. Arm CPU Security Bulletin: Spectre/Meltdown - Arm Developer
  43. [PDF] arXiv:2502.10719v1 [cs.CR] 15 Feb 2025
  44. [PDF] Branch Different - Spectre Attacks on Apple Silicon - Michael Schwarz
  45. Power Systems And The Spectre And Meltdown Threats - IT Jungle
  46. [PDF] Unveiling Security Vulnerabilities of RISC-V Microprocessors
  47. [PDF] Replicating and Mitigating Spectre Attacks on a Open Source RISC ...
  48. A Spectre proof-of-concept for a Spectre-proof web
  49. 20-30% Performance Hit from the Spectre Bug Fix on Ubuntu
  50. [PDF] Restoring the Performance of Indirect Branches In the Era of Spectre
  51. The Spectre And Meltdown Server Tax Bill - The Next Platform
  52. Intel stock down (INTC): Could Meltdown, Spectre exploit benefit ...
  53. More details about mitigations for the CPU Speculative Execution ...
  54. [PDF] SOFTWARE TECHNIQUES FOR MANAGING SPECULATION ... - AMD
  55. RSB-related mitigations - The Linux Kernel documentation
  56. x86 Options (Using the GNU Compiler Collection (GCC))
  57. Speculative Load Hardening — LLVM 22.0.0git documentation
  58. Six stable kernels patching the VMScape Spectre variant - LWN.net
  59. Linux Patched For New "VMSCAPE" Vulnerability Affecting Intel ...
  60. VMSCAPE - The Linux Kernel documentation
  61. Update to enable mitigation against Spectre, Variant 2
  62. Intel Processor Stream Cache August 2025 Security Update
  63. About speculative execution vulnerabilities in ARM-based and Intel ...
  64. Security-Enhanced Linux in Android - Android Open Source Project
  65. FreeBSD-SA-18:03.speculative_execution.asc
  66. An update on Meltdown and Enhanced IBRS | linux - Oracle Blogs
  67. [PDF] AMD64 technology indirect branch control extension
  68. New SLAP & FLOP Attacks Expose Apple M-Series Chips to ...
  69. [PDF] Exploring speculation barriers for RISC-V selective speculation - HAL
  70. VMSCAPE Spectre vulnerability leaks cloud secrets - The Register
  71. New Research Reveals Spectre Vulnerability Persists in Latest AMD ...
  72. [PDF] Branch Privilege Injection: Compromising Spectre v2 Hardware ...
  73. [PDF] Transient-Execution Attacks and Defenses - Daniel Gruss
  74. VMScape: Academics Break Cloud Isolation With New Spectre Attack
  75. ETH Zurich researchers discover new security vulnerability in Intel ...
  76. Detecting Information Leakage through Speculative Cache Attacks ...
  77. SpecTerminator: Blocking Speculative Side Channels Based on ...
  78. [PDF] Formal Verification of Combined Spectre Attacks
  79. Future-Proofing Cloud Security Against Quantum Attacks - arXiv
  80. AI and Secure Code Generation | Lawfare
  81. CSL-KU/SpectreRewind-PoC - GitHub
  82. USENIX Security '25 Technical Sessions
  83. Ubuntu Disables GPU Spectre Mitigations—What That ... - Protectstar
  84. Ubuntu Disables Spectre Mitigations for Intel GPU Performance Boost
  85. Spectre CPU vulnerability yet again discovered in 2018-2024 Intel ...
  86. Specification and Formal Verification of Hardware–Software ...
  87. Cyber Resilience Act | Shaping Europe's digital future
  88. Chips Act | Updates, Compliance, Training
  89. Branch Predictor Isolation in KVM-QEMU - AMD
  90. A New Security Threat to Public Clouds From Old Vulnerabilities
  91. [PDF] DAWG: A Defense Against Cache Timing Attacks in Speculative ...
  92. [PDF] Provably Secure Speculation for the Constant-Time Policy - USENIX
  93. [PDF] Defeating Speculative-Execution Attacks on SGX with HyperRace
  94. VMScape Spectre BTI attack breaks VM isolation on AMD and Intel ...
  95. EU Enacts Broad Cybersecurity Requirements for Hardware and ...
  96. New Spectre Branch Target Injection, Spectre-BTI, Attack Primitives ...
User Avatar
No comments yet.