Systematic Analysis of Programming Languages and Their Execution

Environments for Spectre Attacks

Amir Naseredini

1, 3

, Stefan Gast

2, 3

, Martin Schwarzl

, Pedro Miguel Sousa Bernardo

, Amel Smajic

Claudio Canella

, Martin Berger

1, 5

and Daniel Gruss

2, 3

University of Sussex, U.K.

Lamarr Security Research, Austria

Graz University of Technology, Austria

Instituto Superior T

ecnico, Universidade de Lisboa, Portugal

Turing Core, Huawei 2012 Labs, London, U.K.

Keywords:

Speculative Execution, Spectre Attacks, Programming Languages, Execution Environment.

Abstract:

In this paper, we analyze the security of programming languages and their execution environments (compilers

and interpreters) with respect to Spectre attacks. The analysis shows that only 16 out of 42 execution envi-

ronments have mitigations against at least one Spectre variant, i.e., 26 have no mitigations against any Spectre

variant. Using our novel tool Speconnector, we develop Spectre proof-of-concept attacks in 8 programming

languages and on code generated by 11 execution environments that were previously not known to be affected.

Our results highlight some programming languages that are used to implement security-critical code, but re-

main entirely unprotected, even three years after the discovery of Spectre.

1 INTRODUCTION

In conditional branch instructions, deciding whether

to branch or not requires evaluating the branch con-

dition, which can depend on a slow operation, such

as main memory access. In most programs, branches

are highly predictable from information available be-

fore the branch condition has been evaluated, pri-

marily past outcome of related conditional branches.

This predictability is exploited using branch predic-

tors, adaptively trained as the CPU executes, on

past branching behavior, see (Mittal, 2018) for an

overview. Branch prediction allows CPUs to execute

the predicted direction of the branch long before the

result of evaluating the branch condition is available.

If the prediction is wrong, the execution of the pre-

dicted branch is rolled back, and the other branch

is executed. Note that only the architectural state

is rolled back, but not the microarchitectural state,

which remains visible in contemporary CPUs. Spec-

tre exploits the mismatch between architectural and

microarchitectural state by mistraining branch predic-

tors, so victim code (called gadget) executes a mis-

predicted branch and then rolls back the architectural

state, but not the microarchitectural state. The gad-

get consists of a sequence of instructions, guarded by

a conditional branch, that encodes a secret from the

victim’s own address space into the microarchitec-

tural state, e.g., into the cache by making cache lines

cached or not. This encoded information remains ac-

cessible to attackers after the misprediction is rolled

back by the CPU.

Spectre attacks have so far been demonstrated in

JavaScript (Kocher et al., 2019), native code (Kocher

et al., 2019; Canella et al., 2019), Go (Duete, 2018)

and Rust (Chl

adek, 2020). Consequently, a vast va-

riety of mitigations have been proposed, and some of

them have been deployed in practice. While Melt-

down attacks are mainly mitigated in hardware or mi-

crocode, Spectre attacks mainly rely on mitigations

on the operating-system level, or in compilers and

JIT engines. Given the large number of mitigations

and programming languages with associated execu-

tion environments, it has become unclear which pro-

gramming languages, interpreters, compilers and JIT

engines, have working mitigations today and can se-

curely be used to implement security-critical code,

and which do not.

Spectre does not necessarily work in every single

execution environment. The possibility of being able

to pull off the attack depends on several factors in-

cluding (but not limited to) the runtime environment,

whether it is fast enough (e.g., interpreters might be

too slow for the attack to be pulled off), the com-

piler and the transformations that it enforces on the

code such as optimizations (e.g., whether it emits the

code that is efﬁcient enough for this purpose), or the

language and its constructs (e.g., do branch-predicted

Naseredini, A., Gast, S., Schwarzl, M., Bernardo, P., Smajic, A., Canella, C., Berger, M. and Gruss, D.

Systematic Analysis of Programming Languages and Their Execution Environments for Spectre Attacks.

DOI: 10.5220/0010779300003120

In Proceedings of the 8th International Conference on Information Systems Security and Privacy (ICISSP 2022), pages 48-59

ISBN: 978-989-758-553-1; ISSN: 2184-4356

code sequences exit on the binary level). Hence, it

was not known which languages, compilers, and envi-

ronments need mitigations. We are the ﬁrst to system-

atically study which languages, compilers, and exe-

cution environments need mitigations against Spectre

attacks. The result of this study helps developers of

languages, compilers, and environments to ﬁnd out

whether or not they should implement mitigations.

In this paper, we systematically analyze the se-

curity against Spectre attacks, of the top 30 most-

popular programming languages

, which involves an

analysis of 42 compilers and execution environments.

We categorize the languages and their execution envi-

ronments into three different categories: interpreted,

compiled, and managed languages. We determine

for each of these languages, compilers and runtimes,

whether Spectre mitigations exist and are imple-

mented. The basis of this analysis is publicly avail-

able documentation and direct communication with

developers. We discover that only 16 of the analyzed

execution environments have mitigations for at least

one Spectre variant. Based on this initial analysis, we

perform a full-scale analysis of the existence of Spec-

tre gadgets for each of these languages and environ-

ments. To facilitate our analysis, we present a novel

method and tool, Speconnector. Speconnector allows

us to evaluate and exploit Spectre gadgets indepen-

dent of the programming language to validate leakage

without bi-directional interaction. We use Specon-

nector to develop Spectre proof-of-concept attacks for

16 programming languages, half of which were previ-

ously not known to be affected. Our results highlight

that programming languages and their execution envi-

ronments used to implement security-critical code re-

main entirely unprotected, even three years after the

discovery of the issue, and still continue to leak se-

crets.

To demonstrate the concrete security impact of our

results, we present two case studies that exploit secu-

rity libraries using Spectre attacks. First, we attack

the Alice crypto library, implemented in Java using

the OpenJDK compiler. We demonstrate that we can

leak the secret key used by Alice for encryption pur-

poses by exploiting a Spectre gadget in it. Second,

we attack cryptokit, implemented in OCaml using the

ocamlopt native compiler. In this case study, we show

that by exploiting a Spectre gadget, we can leak secret

data while it resides in memory.

Our work shows that there are still several crit-

ical security libraries implemented in programming

languages suffering from the lack of mitigations.

Security-critical code implemented in these languages

remains entirely unprotected against Spectre-type at-

From https://github.com/madnight/githut.

tacks, even three years after the discovery of the is-

sue. We responsibly disclosed our ﬁndings to the

corresponding vendors and worked with them on so-

lutions. However, we emphasize that this problem

goes beyond these speciﬁc libraries and is a problem

that must be solved by the corresponding compiler,

runtime, or interpreter. Finally, until mitigations are

available in compilers and runtime environments, de-

velopers should be cautious using these programming

languages for security-critical code, and users should

also be alert using security applications implemented

in such languages.

Contributions. Our contributions are:

1. A systematic analysis of the security of program-

ming languages and their execution environments

with respect to Spectre attacks.

2. We introduce Speconnector, a novel tool to evalu-

ate and exploit Spectre gadgets independent of the

programming language.

3. We demonstrate the security impact with two case

studies of security-related libraries, and show that

we can leak secrets from them.

Outline. Section 2 provides background. Section 3

systematically analyzes programming languages for

Spectre mitigations. Section 4 presents our new

tool Speconnector and our threat model. Section 5

presents our systematic analysis of the Spectre sus-

ceptibility of environments using Speconnector. Sec-

tion 6 presents two case studies showcasing our re-

sults. We conclude in Section 7.

2 BACKGROUND

In this section, we provide background on speculative

and transient execution with a focus on Spectre-type

attacks, as well as interpreted, compiled, and man-

aged programming languages.

Speculative Execution. Because programs contain

conditional branching, CPUs often do not know

which instruction needs to be executed next. This oc-

curs, for instance, when the out-of-order execution

reaches a not yet completed conditional branch in-

struction which determines control ﬂow. With spec-

ulative execution, the CPU can save the current reg-

ister state, predict the most likely outcome based on

similar events in the past, and speculatively execute

in the predicted direction. Once the predicted branch

instruction has completed execution and the correct

path is known, the CPU can decide what to do with

the speculatively executed instructions. In the case

of a correct prediction, the CPU simply commits (re-

tires) the instructions in the order of the instruction

Systematic Analysis of Programming Languages and Their Execution Environments for Spectre Attacks

1 if (x < length_of_data) {

2 tmp &= lookup_table[data[x] << 12];

3 }

Figure 1: An example of an index gadget.

stream, making the results visible on the architectural

level. However, if the prediction is not correct, the

CPU rolls back to the saved register state, discards the

result of the wrongly executed instructions, and con-

tinues with the execution of the correct path. The dis-

carded instructions are commonly referred to as tran-

sient instructions (Kocher, 1996; Lipp et al., 2018;

Canella et al., 2019). While the architectural state is

rolled back in the case of a wrong prediction, the mi-

croarchitectural state is not reverted, hence allows to

infer results and side effects of the transiently exe-

cuted instructions.

To make such predictions and maximize the per-

formance, CPUs utilize the Branch Prediction Unit

(BPU), which consists of different prediction mech-

anisms (Mittal, 2018). One such prediction mecha-

nism is the aforementioned conditional branch pre-

diction which is done by the Pattern History Table

(PHT) (Canella et al., 2019). Other mechanisms pre-

dict conditional and indirect jump targets (Kocher,

1996) or return addresses of functions (Maisuradze

and Rossow, 2018; Koruyeh et al., 2018). Indi-

rect jumps are predicted by the Branch Target Buffer

(BTB) (Lee et al., 2017; Evtyushkin et al., 2016;

Kocher et al., 2019), returns by the Return Stack

Buffer (RSB) (Maisuradze and Rossow, 2018; Ko-

ruyeh et al., 2018).

Branch-prediction logic, e.g., BTB and RSB,

is typically not shared across physical cores (Ge

et al., 2016), but sometimes among logical cores

(Maisuradze and Rossow, 2018). Therefore, the CPU

learns only from previous branches executed on the

same physical core.

Transient-Execution Attacks. While speculative and

out-of-order execution signiﬁcantly increase the per-

formance of CPUs (Tomasulo, 1967), these features

also have a signiﬁcant impact on the security of

software running on the CPU. So-called transient-

execution attacks (Canella et al., 2019) have demon-

strated that the effects of transient instructions can be

reconstructed on the architectural level as the microar-

chitectural effects are not reverted. To bring the ef-

fects to the architectural level, these types of attacks

leverage traditional side-channel attacks, e.g., cache

attacks. While the cache has been predominantly ex-

ploited for the transmission of the secret data (Kocher

et al., 2019; Canella et al., 2019; Maisuradze and

Rossow, 2018; Koruyeh et al., 2018), other channels

have also been shown to be effective, e.g., execution

port contention (Bhattacharyya et al., 2019).

Kocher et al. (Kocher et al., 2019) ﬁrst discussed

transient-execution attacks (Canella et al., 2019) us-

ing speculative execution and demonstrated that con-

ditional branches and indirect jumps are potential el-

ements to be exploited to leak data. Subsequent

work has then shown that the idea can be extended

to function returns (Maisuradze and Rossow, 2018;

Koruyeh et al., 2018) and store-to-load forwarding

(Horn, 2018). Canella et al. (Canella et al., 2019) then

systematically analyzed the ﬁeld and demonstrated

that the necessary mistraining can be done in the same

and a different address space due to some predictors

being shared across hyperthreads. Additionally, they

showed that many of the proposed countermeasures

are ineffective and do not correctly target the root

cause of the problem. More recent work (Canella

et al., 2020a) has then analyzed the commonalities of

these attacks instead of the differences (Canella et al.,

2019).

To mitigate all these attacks, various propos-

als have been made by industry and academia.

Canella et al. (Canella et al., 2020b) analyzed the

differences between countermeasures from academia

and industry, highlighting that academia proposes

more radical countermeasures compared to industry.

Proposed mitigations either require hardware changes

(Kiriansky et al., 2018; Yan et al., 2018; Khasawneh

et al., 2019), secret annotation (Schwarz et al., 2020;

Palit et al., 2019; Fustos et al., 2019), new data depen-

dencies (Oleksenko et al., 2018; Carruth, 2018b), or

reduced timer accuracy (Pizlo, 2018; The Chromium

Projects, 2018; Wagner, 2018).

Gadgets. In transient-execution attacks, a gadget is

a piece of code used to transfer the secret informa-

tion from the victim’s side into a covert channel from

which the attacker can then retrieve it. Kocher et al.

(Kocher et al., 2019) introduced the ﬁrst Spectre gad-

get, which is shown in Figure 1. In such a gadget, se-

cret information is stored in memory following the ar-

ray data. A global variable tmp is used to prevent op-

timizing out the memory access. The attacker controls

the value of x, which allows mistraining the branch

for the length check, i.e., the attacker ﬁrst supplies

values for x that are lower than length of data. After

mistraining the branch, the attacker supplies a larger

value, accesses the secret during transient execution,

and encodes it in lookup table, which is shared be-

tween victim and attacker. From there, the attacker

reads using a cache attack. Canella et al. (Canella

et al., 2020a) refer to such a gadget as an index gadget.

Compiled vs Interpreted vs Managed Program Ex-

ecution. An important distinction in program execu-

ICISSP 2022 - 8th International Conference on Information Systems Security and Privacy

Figure 2: Different categories of programming languages based on their translation process. In this ﬁgure, a Perl interpreter is

an example of an interpreter, GCC an example of a compiler, OCaml’s (ocamlc/ocamlrun) compiler process is an example of

a managed language with the translation process in Hybrid Compiler A and OracleJDK shows an example of the translation

process for Hybrid Compiler B.

tion is between interpretation and compilation. The

difference is in whether the program is executed di-

rectly using an interpreter, or with an intermediate

compilation stage where a compiler generates a new

program to be executed. A third option are hybrid

compilers where the resulting ﬁle of the compila-

tion is again interpreted, combining the other two ap-

proaches. We refer to this as managed program exe-

cution. We often speak of execution environment to

mean any of compilers, interpreters, or their hybrids.

Note that this distinction is orthogonal to program-

ming language choice: every language can be inter-

preted, compiled, and executed in hybrids.

All of these approaches to execute a program have

different advantages and disadvantages. For instance,

compiled languages only incur the overhead of trans-

lating the code once, while interpreted languages need

to translate it every time they are being run. Hence,

compilers can perform more sophisticated optimiza-

tions as the time needed for translation is less impor-

tant. LLVM (Lattner and Adve, 2004) is an example

of an optimizing compiler framework. C and C++ are

examples of programming languages that are usually

executed by compilation, although, in principle, they

can also be interpreted. An advantage of interpreted

languages is that they are more portable as only the

interpreter is platform speciﬁc. Another advantage is

that some security problems can be ﬁxed simply by

updating the interpreter, whereas compiled binaries

remain vulnerable until recompiled individually. As

the interpreter needs to hold more information about

the run-time state of the application, interpreted ap-

plications typically require more memory during exe-

cution than compiled applications. Perl is an example

of a languages that is usually interpreted and not com-

piled.

Hybrid compilers seek to combine the advantages

of compiled and interpreted languages. We distin-

guish several variants of hybrid compilers: Figure 2

shows the two common variants. In the ﬁrst vari-

ant, a compiler ﬁrst translates the code into platform-

independent code, allowing for more sophisticated

optimizations, as well as allowing for portability.

When running the application, an interpreter executes

this platform-independent code. An example of such

a hybrid compiler is Ocaml when using ocamlc and

ocamlrun: ocamlc carries out the ﬁrst part to com-

pile the code implemented by the developer, and then

ocamlrun interprets the code generated by ocamlc.

In the second variant, the compiler again generates

platform-independent code. In the second phase, the

JIT-compiler uses the platform-independent code to

produce the executable code which is interpreted by

the interpreter. The interpreter then provides feedback

to the JIT-compiler on how to improve the generated

code. An example of such hybrid compilers are Ora-

cleJDK and C# .NET. Figure 2 provides an illustration

of all four aforementioned cases.

3 SPECTRE MITIGATIONS BY

LANGUAGE AND RUNTIME

When it comes to mitigating Spectre-type attacks,

compilers and interpreters play a crucial role as they

generate the code that is exploited later on. In this

section, we investigate different compilers and inter-

preters to determine whether they provide methods to

mitigate such attacks. Our systematic analysis con-

siders 42 different execution environments which are

used to translate the top 30 most-popular program-

ming languages according to GitHub in the third quar-

ter of 2020. The languages encompass compiled, in-

terpreted, and managed languages.

Unfortunately, most of the investigated compilers

and interpreters do not provide any published infor-

mation on mitigations. Hence, as an additional source

of information, we contacted developers of the re-

spective compilers and interpreters. Our investiga-

tion showed that the majority of the investigated com-

pilers and interpreters did not provide any informa-

Systematic Analysis of Programming Languages and Their Execution Environments for Spectre Attacks

Table 1: Interpreted programming languages and their inter-

preters and which Spectre variants they can mitigate based

on the available documentation and direct responses from

interpreters’ developers. Symbols show whether Spectre

mitigations are not available based on the communication

with developers ( ), or it was unclear whether there are any

mitigations available ( ).

Attack

PLs

Ruby

(MRI)

PHP

Shell

(Bash)

Perl

PowerShell

(pwsh)

TSQL

Lua

Vim

script

Emacs

Lisp

Spectre-PHT

1 2

Spectre-BTB

1 2

Spectre-RSB

1 2

Spectre-STL

1 2

(support, 2020)

tion whether the lack of Spectre mitigations was be-

cause the developers believed their software was safe

against Spectre-type attacks. We defer a discussion of

the possibility of Spectre-type attacks to Section 5.

Also, based on our investigations, there are sev-

eral reasons that made the vulnerable execution envi-

ronments ending up not having any mitigations. One

of the main reasons is that language designers mostly

do not take Spectre attacks seriously and believe that

it is impossible to run the attack using their execu-

tion environment, such as in CPython and PyPy. An-

other reason is that language designers are not aware

of the problem in their product, such as in Groovy.

For some languages with several layers of compila-

tion, e.g., managed languages, the designers do not

believe that mitigations should be provided to soft-

ware developers on their layer and the problem should

be resolved in a another layer, e.g., the Clojure de-

signers believe that this problem should be addressed

in JVM. However, this is technically impossible for

Spectre-PHT, as the software developer has to ex-

plicitly deﬁne where to avoid speculation (cf. C’s

array index nospec). Ironically, the JDK develop-

ers conﬁrm our view, that it is not possible to address

the problem in JDK itself (Gross, 2019) without in-

formation provided by the software developer in the

programming language and environment running on

top of JDK. This leaves us in the unfortunate situa-

tion that software developers have no possibility to

mitigate Spectre when choosing certain programming

languages and environments at all. Finally, some of

the designers also think that this problem should be

addressed at the kernel level, which again is not pos-

sible for Spectre-PHT.

Below, we brieﬂy describe the process for each

category as well as the results of our systematic anal-

ysis in more detail, and we rely on the categoriza-

tion of Spectre-type attacks provided by Canella et al.

(Canella et al., 2020a).

Interpreted Languages. In this paper, we study 9 dif-

ferent interpreted programming languages and their

respective interpreters (Table 1). As a ﬁrst step in our

analysis, we conducted a thorough survey of the pub-

licly available documentation of each interpreter. This

step showed that the documentation for 8 of the 9 an-

alyzed interpreters does not contain any information

regarding potential mitigations for Spectre. While the

documentation for TSQL (support, 2020) contained

some information regarding Spectre mitigations, it

was unclear whether any mitigations are implemented

and which Spectre variants are considered in potential

mitigations.

For a more thorough analysis, we analyzed com-

mits made since the public disclosure of Spectre for

any indication of available mitigation in the 8 inter-

preters that do not provide any public information.

Unfortunately, this step did not provide any additional

insights. Hence, to complete our investigation, we

contacted the developers of the respective interpreters

to ask for information about potentially implemented

mitigations.

In this step, the developers of Perl conﬁrmed that

their interpreter does indeed not contain any mitiga-

tions for any variant of Spectre

. For Ruby (MRI)

and PHP, we unfortunately were not able to discuss

the issue with the developers. Nevertheless, our re-

sults gathered in the ﬁrst two steps show that we are

not aware of any mitigation in these two interpreters.

Our analysis for interpreters illustrates that it is un-

clear for 7 of the 9 analyzed interpreters if they have

mitigations implemented to mitigate Spectre attacks

Compiled Languages. Our analysis of compiled pro-

gramming languages shows a different result com-

pared to the analysis of interpreters. In this analy-

sis, we used the same approach as for the interpreted

languages and their interpreters, i.e., searched public

documentation, analyzed commits, and contacted the

developers.

Table 2 presents the results of our analysis. The

results show that 13 of the 15 considered compilers

provide information about Spectre, but only 12 of

them claim to have implemented mitigations for at

least one of the existing variants. While all 12 provide

mitigations against Spectre-PHT, only 10 provide

mitigations for Spectre-BTB. Interestingly, only Go

provides a mitigation for Spectre-RSB, while none of

the compilers document mitigations against Spectre-

STL. In a conversation, the developers of Microsoft’s

C/C++ compiler conﬁrmed that, despite missing doc-

umentation, their compiler provides a Spectre-STL

mitigation. The developers of ocamlopt also con-

ﬁrmed in direct communication that their compiler

Dan Book conﬁrmed this via email

ICISSP 2022 - 8th International Conference on Information Systems Security and Privacy

Table 2: Compiled programming languages and their compilers and which Spectre variants they can mitigate based on the

available documentation and direct responses from the respective compilers’ developers. Symbols show whether Spectre

mitigations are available based on the documentation ( ) or communication with developers ( ), not available based on the

communication with developers ( ), or it was unclear whether there are any mitigations available ( ).

Attack

PLs

C++

(GCC)

C++

(MS)

C++

(Intel)

C++

(LLVM)

(GCC)

(MS)

(Intel)

(LLVM)

Rust

(LLVM)

Swift

(LLVM)

Objective-C

(LLVM)

Haskell

(GHC)

OCaml

(ocamlopt)

Spectre-PHT

3 5 8 10 12 5 8 10 12 12 12 12 14

Spectre-BTB

3 6 9 10 13 6 9 10 13 13 13 13 14

Spectre-RSB

3 7 9 11 7 9 11 14

Spectre-STL

4 9 11 9 11 14

(Munday, 2020)

(Randall, 2020)

(GCC.GNU.ORG, 2020)

(Lu, 2018)

(Biener, 2018)

(Pardoe, 2018)

(Jiang, 2018)

(Viet H Intel, 2020)

(Carruth, 2020)

(Carruth, 2018a)

(Bacarella, 2020)

does not provide any form of mitigation against any

Spectre variant. Unfortunately, we were not able to

get any information about the existence of mitigations

for the two remaining compilers, i.e., DM and Haskell

(GHC).

Based on our analysis, the Go compiler has the

best situation regarding its mitigations against Spec-

tre variants as it contains mitigations for 3 of the 4

Spectre variants discussed by Canella et al. (Canella

et al., 2020a).

Managed Languages. Table 3 shows the results of

our analysis of 13 programming languages and their

18 respective hybrid compilers. This analysis pro-

vides several interesting insights. For instance, except

for the JavaScript compilers SpiderMonkey (Wag-

ner, 2018; de Mooij, 2019), V8 (The Chromium

Projects, 2018; Mcilroy et al., 2019), Chakra (Mi-

crosoft, 2018), and the Java compiler GraalVM (Or-

acle, 2020), none of the other compilers for man-

aged languages provide any form of public documen-

tation of mitigations against at least one of the Spec-

tre variants discussed by Canella et al. (Canella et al.,

2020a). The ﬁrst three mitigate Spectre-PHT and

Spectre-BTB while GraalVM only has mitigations for

Spectre-PHT. Similar to the previous case, we again

observe that the compilers that do have mitigations,

all mitigate Spectre-PHT. While we were able to ﬁnd

documentation regarding Spectre for the Java com-

piler OpenJDK, the documentation indicates that no

mitigations are available.

To counteract the lack of publicly available infor-

mation on mitigations, we contacted the developers

of the PyPy, C#, Scala, Elixir and OCaml (ocamlc/o-

Shayne Hiet-Block from Microsoft conﬁrmed this via

Maciej Fijalkowski conﬁrmed this via email

Eric Meadows-J

onsson conﬁrmed this via email

Ilya Pleskunin conﬁrmed this via email

Paul King conﬁrmed this via email

camlrun) compilers to gather information on whether

they provide mitigations. In all 5 cases, this discus-

sion showed that none of them contain any mitiga-

tions. In addition, the documentation for OracleJDK

(Oracle, 2021) is hinting at Spectre mitigations, how-

ever, it is unclear if any mitigation is implemented and

which Spectre variants are the targets in the potential

mitigations. Unfortunately, the status of the remain-

ing 7 compilers from this category remain unclear as

we did not receive a response. These 7 compilers

are Dart, TypeScript, CoffeeScript, Clojure, CPython,

Groovy and Kotlin.

4 Speconnector

This part describes the goal, tasks, and advantages of

the Speconnector tool. Speconnector is written in C,

but works for any target language.

The goal of Speconnector is to determine, easily

and independent from the target language, whether a

given execution environment is vulnerable to Spectre.

Note that we do not claim that Speconnector is com-

plete in that it detects all possible microarchitectural

attacks. Instead we give a lower bound on the lan-

guages and their execution environments that are still

vulnerable.

Threat Model. Speconnector demonstrates that an at-

tack is possible under a regular Spectre attack threat

model: The attacker is a co-located program running

under the same operating system and is able to exe-

cute arbitrary code on the victim machine. The victim

code has an interface that we can interact with, e.g., a

local API or local server can be a potential target code.

Whether an attack is possible under this threat model

only depends on whether the victim leaks. Therefore,

we focus on the illegal data leakage and use Specon-

We plan to open source the tool.

Systematic Analysis of Programming Languages and Their Execution Environments for Spectre Attacks

Table 3: Managed programming languages and their compilers and which Spectre variants they can mitigate based on the

available documentation and direct responses from compilers’ developers. Symbols show whether Spectre mitigations are

available based on the documentation ( ), available but partially effective based on the documentation ( ), not available

based on the documentation ( ) or communication with developers ( ), or it was unclear whether there are any mitigations

available ( ).

Attack

PLs

Dart

Java

(OracleJDK)

Java

(OpenJDK)

Java

(GraalVM)

JavaScript

(SpiderMonkey)

JavaScript

(V8)

JavaScript

(Chakra)

TypeScript

CoffeeScript

Python

(PyPy)

Scala

Elixir

Clojure

Python

(CPython)

OCaml

(ocamlc/ocamlrun)

Kotlin

Groovy

Spectre-PHT

15 16 17 18,19 20 22 23 24 25 26 27 28 29

Spectre-BTB

15 16 18, 19 20, 21 22 23 24 25 26 27 28 29

Spectre-RSB

15 16 23 24 25 26 27 28 29

Spectre-STL

15 16 21 23 24 25 26 27 28 29

(Oracle, 2021)

(Gross, 2019)

(Oracle, 2020)

(Wagner, 2018)

(de Mooij, 2019)

(The Chromium Projects, 2018)

(Mcilroy et al., 2019)

(Microsoft, 2018)

(Malak and nilskp, 2018)

(Tur, 2020)

(Bacarella, 2020)

nector to measure and evaluate the victim leakage.

While this shows that an attack is possible, crafting

a concrete end-to-end exploit for each language re-

quires further engineering steps.

Algorithm. One of the main tasks of Speconnec-

tor is to establish shared memory between itself and

the victim application. Hence, the target applica-

tion ﬁrst allocates 256 pages of memory and ﬁlls it

with a known magic value while Speconnector also

allocates the same amount of memory in its own ad-

dress space, i.e., the lookup table. Then, Speconnec-

tor uses the /proc/[pid]/mem ﬁle of the victim to scan

for the pages that contain the magic value. Once it

ﬁnds them, Speconnector uses the the publicly avail-

able PTEditor (Schwarz et al., 2018) to set the victim

pages page frame numbers to the page frame num-

bers of its own lookup table, to establish shared mem-

ory between the two processes. As a result, any vic-

tim access to one of the now shared pages results in a

cache hit when Speconnector performs Flush+Reload

to distinguish between cached and uncached memory.

The advantage of this approach is simplicity: in-

stead re-implementing cache attacks in all program-

ming languages, we can rely on a well understood

primitive written in C, e.g., Flush+Reload. For the

analysis, the only part that needs to be done in the

victim is to implement a victim gadget and to allocate

256 pages and ﬁll them with the known magic value.

5 ATTACK FEASIBILITY BY

LANGUAGE AND RUNTIME

In this section, we present the results of using Specon-

nector to determine whether we can establish a covert

channel and exploit speculative execution in our set of

selected programming languages and their execution

environments. To investigate the potential vulnera-

bilities, we ﬁrst evaluate each compiler/interpreter to

determine whether we can establish a covert channel.

Such a covert channel is a necessary building block

for Spectre attacks as it gives the attacker the capabil-

ity of bringing secret data from the microarchitectural

state to the architectural level. To determine whether

we can establish a covert channel, Speconnector es-

tablishes shared memory between itself and the vic-

tim application. The victim then accesses the shared

lookup table in a known pattern which Speconnec-

tor tries to reconstruct. If Speconnector cannot re-

construct the pattern, then it is not possible for us

to establish a covert channel. One potential reason

for that can be that the target language uses a differ-

ent memory layout than C. Then, we evaluate each

compiler/interpreter to determine whether we can ex-

ploit speculative execution by adding a gadget, mis-

training the victim, and using Speconnector to leak

the victim’s secret data. Because of the nature of

the vulnerability and the attack, while a positive re-

sult for an execution environment in the experiments

shows that the corresponding execution environment

is vulnerable and exploitable, a negative result does

not guarantee the absence of the vulnerability nor the

exploitability.

The experiments were run using different ma-

chines for different programming languages and their

execution environments. We listed the CPU, the op-

erating system, and the execution environment ver-

sion for each language and its compiler/interpreter in

Appendix A. Table 4 shows the results of our anal-

ysis. For completeness, we performed the experi-

ments on the execution environments listed, even if

they were very similar, e.g., the both were using JVM

in their compilation. The reasoning behind this, is that

the construct of each language in its execution envi-

ronment should be protected against different Spec-

tre variants as well as the composition of different

constructs, as certain mitigations, e.g., for Spectre-

ICISSP 2022 - 8th International Conference on Information Systems Security and Privacy

Table 4: Programming languages and their compilers/interpreters and the result whether they are vulnerable to at least one

variant of Spectre attack in practice. The ﬁrst row (depends on settings) shows if compilers/interpreters are not vulnerable (∗)

or are vulnerable (-) if the existing best practices for them are followed.

Attack

PLs

C++ (GCC)

C++ (MS)

C++ (Intel)

C++ (LLVM)

C (GCC)

C (MS)

C (Intel)

C (LLVM)

Rust (LLVM)

Swift (LLVM)

Objective-C

(LLVM)

Haskell (GHC)

OCaml (ocamlopt)

Dart

Java (OracleJDK)

Java (OpenJDK)

Java (GraalVM)

JavaScript

(SpiderMonkey)

JavaScript (V8)

JavaScript

(Chakra)

TypeScript

CoffeeScript

Python (PyPy)

Scala

Elixir

Clojure

Python (CPython)

OCaml

(ocamlc/ocamlrun)

Kotlin

Groovy

Emacs Lisp

Ruby (MRI)

PHP

Shell (Bash)

Perl

PowerShell

(pwsh)

TSQL

Lua

Vim script

Depends on setting ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ - ∗ - - - - - ∗ ∗ ∗ ∗ - - - - - - - - - - - - - - - - - - - -

Covert Channel ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✗ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✗ ✓ ✓ ✗ ✓ ✗

Spectre Attack ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✗ ✗ ✓ ✗ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✗ ✓ ✓ ✗ ✗ ✗ ✓ ✓ ✓ ✗ ✗ ✗ ✗ ✓ ✗ ✗ ✗ ✗

PHT, can only be implemented on the language level.

Therefore, we need to take a look at the problem at

the language level.

We now discuss the results in the previously out-

lined categories of interpreted, compiled, and man-

aged languages individually.

Interpreted Languages. Using the approach dis-

cussed, we evaluate all our interpreted languages.

During this analysis, we were able to exploit Perl’s

interpreter, successfully demonstrating a covert chan-

nel and leaking data using a Spectre attack. The Perl

interpreter does not provide any mitigations (cf. Sec-

tion 3), making it infeasible to protect an application

against such attacks. Out of the 9 interpreters we an-

alyzed (cf. Table 4), only the Perl interpreter was

vulnerable to both establishing a covert channel and

a Spectre attack. A potential explanation is that the

speculation window might have been too small for

the other interpreters to ﬁt the attack in it. In the

remaining 8 interpreters, we were still able to estab-

lish a cache covert channel in 5 of them even though

we were not able to exploit them with a Spectre at-

tack. We were not able to establish a covert channel

in TSQL, Shell (bash) and Vim script. However, this

does not mean that these interpreters are safe against

Spectre attacks nor against establishing a covert chan-

nel. In total, we were able to establish a covert chan-

nel in 67 % and exploit 11 % of the analyzed inter-

preters.

Compiled Languages. In our analysis of covert chan-

nels in compiled languages, we were able to estab-

lish a covert channel in 14 out of 15 (93 %) of the

analyzed combinations of languages and compilers.

12 out of the 15 (80 %) compilers generate code that

is vulnerable against a Spectre attack. This includes

languages and compilers that have been known to be

vulnerable but also ones that have so far not been ana-

lyzed. One example for such a never before analyzed

language and compiler is OCaml with the ocamlopt

compiler where we were able to demonstrate both a

covert channel and a Spectre attack. While we were

able to establish a covert channel in Swift (LLVM)

and Haskell (GHC), we were not able to exploit them

using a Spectre attack. Compilers annotated with a *

in Table 4 are not exploitable or at least less vulnera-

ble in case the available mitigations are used and best

practices are followed.

Managed Languages. For managed languages, we

were able to demonstrate a functioning covert channel

in all 18 cases (100 %). Out of the 18 language and

compiler combinations, we were able to demonstrate

a Spectre attack in 14 (78 %) of them. This includes

Dart, Java, C#, Scala Groovy, Kotlin and OCaml

(ocamlc/ocamlrun), which were so far not known to

be vulnerable, i.e., no Spectre attack on these has

been demonstrated before. Similar as to compiled

languages, there are several instances, again marked

with a * in Table 4, where the usage of the available

mitigations and following the best practices removes

or at least reduces the impact of the vulnerability.

Our investigation of all three language categories

provides several interesting insights. First, contrary

to interpreted and compiled languages, we were able

to establish a covert channel in all analyzed managed

languages and compilers, while in the others there

was at least one where we were not able to estab-

lish a covert channel. Second, compilers for com-

piled languages are the most vulnerable to Spectre

attacks if mitigations are not used and best practices

are not followed. Third, in all three categories, we

were able to extract data using a Spectre attack in at

least one instance. This further highlights that many

languages and their respective compilers/interpreters

have not considered Spectre attacks even 3 years after

they were introduced to the public.

6 CASE STUDIES

In this section, we present two case studies, each

using one of the vulnerable programming languages

taken from Table 4. For both, we demonstrate how a

Systematic Analysis of Programming Languages and Their Execution Environments for Spectre Attacks

Spectre attack can be used to leak secret information

from real-world libraries. Furthermore, we argue that

a mitigation at the compiler level prevents our attacks.

6.1 Alice - Java

In our ﬁrst case study, we investigate Alice

, a crypto

library written in Java which provides encryption/de-

cryption with AES of byte arrays and ﬁles. Alice sup-

ports different key sizes, block modes and padding

schemes. Our goal is to ﬁnd and exploit speculative

execution vulnerabilities to leak the secret key which

is being used to encrypt/decrypt the plaintext in Alice

encryption and decryption methods.

We ﬁrst performed an in-depth assessment of this

library and the way that it should be used. The library

contains three main Java classes. Class Alice which is

the main API in the library for encryption purposes.

Class AliceContext which provides the context to be

passed to class Alice to create a new object of it. And

class AliceContextBuilder which is used to build the

context. More information about Alice library is pro-

vided on their publicly available documents.

Our attack uses three Java classes, Main, Enc and

Victim. The Main class is responsible for starting two

threads on the same physical core, one uses Enc while

the other uses Victim. Enc creates an instance of an

unmodiﬁed Alice and performs the encryption using

the context generated by AliceContextBuilder and the

password stored within Enc. Our Victim class con-

tains an index gadget (cf. Figure 1) mistrained and

used by the attacker to leak the secret information.

As a ﬁrst step in our attack, our Main class starts

both the encryption and the victim containing the gad-

get. Once this is done, we use Speconnector (cf. Sec-

tion 4) simply to ease the exploitation, but note that

extracting the data is also possible directly in Java.

Speconnector establishes a shared memory with the

victim by allocating 256 pages and ﬁlling them with

the known magic value. The victim is mistrained to

perform the speculative out-of-bounds access which

causes a secret-dependent cache access on our shared

memory. To extract the password stored in Enc,

Speconnector constantly performs Flush+Reload on

the memory shared with the victim. As OpenJDK

does not contain any Spectre mitigations (cf. Table 3),

Speconnector can successfully extract the password,

compromising the whole encryption system.

6.2 Cryptokit - OCaml

Our second case study performs a thorough analy-

sis of cryptokit (Leroy, 2020), a widely used OCaml

https://rockaport.github.io/alice/

crypto library. As Tables 2 and 3 show, the documen-

tation of OCaml already indicates that no mitigations

are available against Spectre attacks. It is an impor-

tant case study, as so far OCaml has not been shown

to be affected.

In this analysis, we encountered several factors

that complicate the analysis. First, OCaml can be

either compiled into native machine code using the

ocamlopt compiler, or it can be compiled into byte-

code using the ocamlc compiler, which is then exe-

cuted by the ocamlrun runtime. Depending on the

compiler being used, it can either be regarded as a

compiled or a managed language. Second, the en-

vironment is important as well since some gadgets

show themselves only in some particular conﬁgura-

tions. For example, while we could not cause any data

leakage with our Spectre index gadget when using the

ocamlc bytecode compiler and the ocamlrun runtime

on an older Intel Core2Duo T9600 CPU, the exact

same gadget worked well when run on a more modern

Intel Core I7-6700K CPU. When compiled to native

code using the ocamlopt compiler, the same source

code produces a gadget that works on both machines.

For best reproducibility, we therefore only used the

ocamlopt native compiler in the following case study.

The cryptokit library implements a variety of

cryptographic primitives for use in security-sensitive

applications, including symmetric-key ciphers, pub-

lic-key cryptography, and hash functions. Our manual

analysis has not shown an exploitable Spectre gad-

get within the library itself, but the possibility ex-

ists that the application that uses it leaks the sen-

sitive data processed by the library by executing a

gadget while this data is directly used or parts of

it remain in memory. For example, cryptokit has a

function transform_string t s, which applies the

given transform object t to the given string s. The

transform object itself describes the desired crypto-

graphic action, including its parameters. For AES

encryption, these include the key and the initializa-

tion vector (IV). After the transformation, the internal

state of the transform object t is wiped, but this does

not include the key and the IV. Furthermore, the string

s is not wiped, either. The reason is that, in OCaml,

strings are passed by reference across function calls.

This makes it unsafe for the library function to over-

write these strings as the calling code might still need

them. Therefore, the application itself is responsible

for wiping the key, the IV and the plaintext. How-

ever, it is worth noting that a direct hint about this is

missing in the current documentation (version 1.16.1)

of the library (Leroy, 2020) even though it offers a

function wipe_string s for this purpose. Further-

more, the ofﬁcial OCaml documentation even states

ICISSP 2022 - 8th International Conference on Information Systems Security and Privacy

that strings should be treated as being immutable and

advises against overwriting them (Leroy et al., 2020).

To verify and substantiate this ﬁnding, we per-

formed the following experiment. Following a best-

practice example of using cryptokit, we wrote a proof-

of-concept application that encrypts user-provided

plaintext. Similar to the Java case study in the pre-

vious section, we allocate 256 contiguous pages us-

ing OCaml’s Array1 module and ﬁll them with the

known magic value. Then we add a Spectre gadget to

the application. Using that gadget to perform specu-

lative out-of-bounds accesses on a string and connect-

ing Speconnector to it, we were able to successfully

reconstruct the original plaintext after encrypting it

and after the last reference to the plaintext went out of

scope. To ﬁnd the actual location of the plaintext in

memory, we computed the required offset for the out-

of-bounds access in the proof-of-concept application

itself. This showed that the offset is the same each

time the program is run, making it predictable for the

attacker. Obtaining the key or the IV instead of the

plaintext should also be possible using the same ap-

proach. By this, we show that an OCaml application

can leak sensitive data via transient execution side-

channels as long as that data is in memory. As nei-

ther the native compiler (ocamlopt) nor the bytecode

compiler (ocamlopt) and runtime (ocamlrun) provide

any form of mitigations, it is the task of the applica-

tion developer to ensure that no Spectre gadget is exe-

cuted while sensitive data resides in memory. To wipe

sensitive data from memory, the programmer has to

overwrite strings which are otherwise considered to

be immutable by the language.

Furthermore, sensitive data can also remain in in-

ternal input or output buffers, which cannot be over-

written by the application developer. For example,

to read ﬁles, OCaml uses channel objects, which are

buffered (OCAML.ORG, 2021) yet provide no means

of wiping that buffer (Leroy et al., 2020). We veri-

ﬁed that sensitive data can indeed be leaked from such

buffers by modifying our experiment to leak the data

directly from the input buffer of the standard input

channel. Again, we computed the offset for the out-

of-bounds access in the victim. We observed that Ad-

dress Space Layout Randomization (ASLR) leads to

different offsets each time the program is run, because

the channel buffer is stored in another memory map-

ping than the OCaml strings. However, the offset of

the buffer within its memory mapping itself is con-

stant. Turning off ASLR results in a constant offset

between the OCaml string and the channel buffer.

In conclusion, sensitive data might live longer in

memory than the developer might expect and, there-

fore, also be susceptible to Spectre attacks for quite

a long time. Hence, it is imperative that OCaml pro-

vides ways for a developer to either reliably remove

data from sensitive buffers or to hinder transient exe-

cution at all.

7 CONCLUSION

We presented a systematic analysis of different pro-

gramming languages and their respective compiler-

s/interpreters against Spectre attacks. Our analysis

uncovered Spectre attacks in 16 different program-

ming languages with 8 of them not investigated so

far and not known to be vulnerable. We also demon-

strated practical proof-of-concept attacks and eval-

uated their applicability to these programming lan-

guages and their respective execution environments.

With Speconnector, we presented a novel approach

and tool that can be used to quickly verify whether a

programming language and execution environment is

vulnerable to Spectre attacks. We further presented

two case studies of real world libraries in two differ-

ent programming languages, demonstrating that they

are susceptible to Spectre attacks. Our results indi-

cate that it is necessary to do more research into mit-

igations that target a wide range of programming lan-

guages and execution environments.

REFERENCES

Bacarella, M. (2020). Spectre mitigations in ocaml

compiler?! https://discuss.ocaml.org/t/spectre-

mitigations-in-ocaml-compiler/6718.

Bhattacharyya, A., Sandulescu, A., Neugschwandt ner, M.,

Sorniotti, A., Falsaﬁ, B., Payer, M., & Kurmus, A.

(2019). SMoTherSpectre: exploiting speculative exe-

cution through port contention. In CCS.

Biener, R. (2018). GCC 7.3 released https://lwn.net/

Articles/745385.

Canella, C., Khasawneh, K. N., & Gruss, D. (2020a).

The Evolution of Transient-Execution Attacks. In

GLSVLSI.

Canella, C., Pudukotai Dinakarrao, S. M., Gruss, D., &

Khasawneh, K. N. (2020b). Evolution of Defenses

against Transient-Execution Attacks. In GLSVLSI.

Canella, C., et al. (2019). A Systematic Evaluation of Tran-

sient Execution Attacks and Defenses. In USENIX Se-

curity Symposium. Extended classiﬁcation tree and

PoCs at https://transient.fail/.

Carruth, C. (2018a) https://reviews.llvm.org/D41723.

Carruth, C. (2018b). RFC: Speculative Load Hardening (a

Spectre variant #1 mitigation).

Carruth, C. (2020). Speculative load hardening https://llvm.

org/docs/SpeculativeLoadHardening.html.

Systematic Analysis of Programming Languages and Their Execution Environments for Spectre Attacks

Chl

adek, J. (2020). rust-spectre https://github.com/

movrsprbp/rust-spectre.

de Mooij, J. (2019). [Meta] Spectre JIT mitigations https:

//bugzilla.mozilla.org/show bug.cgi?id=1430049.

Duete, L. (2018). spectre-go https://github.com/lucasduete/

spectre-go.

Evtyushkin, D., Ponomarev, D., & Abu-Ghazaleh, N.

(2016). Jump over ASLR: Attacking branch predic-

tors to bypass ASLR. In MICRO.

Fustos, J., Farshchi, F., & Yun, H. (2019). SpectreGuard:

An Efﬁcient Data-centric Defense Mechanism against

Spectre Attacks. In DAC.

GCC.GNU.ORG (2020). Other built-in functions provided

by gcc https://gcc.gnu.org/onlinedocs/gcc-10.2.0/gcc/

Other-Builtins.html#Other-Builtins.

Ge, Q., Yarom, Y., Cock, D., & Heiser, G. (2016). A Sur-

vey of Microarchitectural Timing Attacks and Coun-

termeasures on Contemporary Hardware. Journal of

Cryptographic Engineering.

Gross, A. (2019). Java and speculative execution vulner-

abilities https://mail.openjdk.java.net/pipermail/vuln-

announce/2019-July/000002.html.

Horn, J. (2018). speculative execution, variant 4: specula-

tive store bypass.

Jiang, J. L. (2018). Using intel® compilers to mit-

igate speculative execution side-channel issues

https://software.intel.com/content/www/us/en/

develop/articles/using-intel-compilers-to-mitigate-

speculative-execution-side-channel-issues.html.

Khasawneh, K. N., Koruyeh, E. M., Song, C., Evtyushkin,

D., Ponomarev, D., & Abu-Ghazaleh, N. (2019). Safe-

Spec: Banishing the Spectre of a Meltdown with

Leakage-Free Speculation. In DAC.

Kiriansky, V., Lebedev, I., Amarasinghe, S., Devadas, S., &

Emer, J. (2018). DAWG: A Defense Against Cache

Timing Attacks in Speculative Execution Processors.

In MICRO.

Kocher, P., et al. (2019). Spectre Attacks: Exploiting Spec-

ulative Execution. In S&P.

Kocher, P. C. (1996). Timing Attacks on Implementations

of Diffe-Hellman, RSA, DSS, and Other Systems. In

CRYPTO.

Koruyeh, E. M., Khasawneh, K., Song, C., & Abu-

Ghazaleh, N. (2018). Spectre Returns! Speculation

Attacks using the Return Stack Buffer. In WOOT.

Lattner, C. & Adve, V. S. (2004). LLVM: A compilation

framework for lifelong program analysis & transfor-

mation. In IEEE / ACM International Symposium on

Code Generation and Optimization – CGO.

Lee, S., Shih, M., Gera, P., Kim, T., Kim, H., & Peinado,

M. (2017). Inferring Fine-grained Control Flow Inside

SGX Enclaves with Branch Shadowing. In USENIX

Security Symposium.

Leroy, X. (2020). cryptokit/cryptokit.mli at release1161

https://github.com/xavierleroy/cryptokit/blob/

release1161/src/cryptokit.mli#L148.

Leroy, X., Doligez, D., Frisch, A., Garrigue, J., R

emy, D.,

& Vouillon, J. (2020). The OCaml system release 4.11

– Documentation and user’s manual https://caml.inria.

fr/pub/docs/manual-ocaml/.

Lipp, M., et al. (2018). Meltdown: Reading Kernel Memory

from User Space. In USENIX Security Symposium.

Lu, H. (2018). x86: Cve-2017-5715, aka spectre

https://gcc.gnu.org/legacy-ml/gcc-patches/2018-

01/msg00422.html.

Maisuradze, G. & Rossow, C. (2018). ret2spec: Speculative

Execution Using Return Stack Buffers. In CCS.

Malak, M. & nilskp (2018). Meltdown/spectre https://users.

scala-lang.org/t/meltdown-spectre/2195.

Mcilroy, R., Sevcik, J., Tebbi, T., Titzer, B. L., & Ver-

waest, T. (2019). Spectre is here to stay: An

analysis of side-channels and speculative execution.

arXiv:1902.05178.

Microsoft (2018). Mitigating speculative execution

side-channel attacks in Microsoft Edge and Internet

Explorer https://blogs.windows.com/msedgedev/

2018/01/03/speculative-execution-mitigations-

microsoft-edge-internet-explorer/.

Mittal, S. (2018). A Survey of Techniques for Dynamic

Branch Prediction. arxiv:1804.00261 http://arxiv.org/

abs/1804.00261.

Munday, M. (2020). consider extending ’-spectre’ op-

tion to other architectures https://github.com/golang/

go/issues/38066.

OCAML.ORG (2021). File manipulation https://ocaml.org/

learn/tutorials/ﬁle manipulation.html.

Oleksenko, O., Trach, B., Reiher, T., Silberstein, M., & Fet-

zer, C. (2018). You Shall Not Bypass: Employing

data dependencies to prevent Bounds Check Bypass.

arXiv:1805.08506.

Oracle (2020). Oracle graalvm enterprise edition 20

guide https://docs.oracle.com/en/graalvm/enterprise/

20/docs/reference-manual/jvm/Options/.

Oracle (2021). Oracle JVM Security Enhance-

ments https://docs.oracle.com/en/database/oracle/

oracle-database/21/nfcon/oracle-jvm-security-

enhancements-274058639.html.

Palit, T., Monrose, F., & Polychronakis, M. (2019). Mitigat-

ing data leakage by protecting memory-resident sen-

sitive data. In ACSAC.

Pardoe, A. (2018). Spectre mitigations in msvc

https://devblogs.microsoft.com/cppblog/spectre-

mitigations-in-msvc/.

Pizlo, F. (2018). What Spectre and Meltdown mean for We-

bKit.

Randall, K. (2020). consider extending ’-spectre’ op-

tion to other architectures https://github.com/golang/

go/issues/38066.

Schwarz, M., Lipp, M., & Canella, C. (2018).

misc0110/PTEditor: A small library to mod-

ify all page-table levels of all processes

from user space for x86 64 and ARMv8

https://github.com/misc0110/PTEditor.

Schwarz, M., Lipp, M., Canella, C., Schilling, R., Kargl, F.,

& Gruss, D. (2020). ConTExT: A Generic Approach

for Mitigating Spectre. In NDSS.

support, M. (2020). Kb4073225 - sql server guid-

ance to protect against spectre, meltdown

ICISSP 2022 - 8th International Conference on Information Systems Security and Privacy

and micro-architectural data sampling vul-

nerabilities https://support.microsoft.com/en-

us/help/4073225/kb4073225-guidance-protect-

sql-server-against-spectre-meltdown.

The Chromium Projects (2018). Mitigating Side-

Channel Attacks https://www.chromium.org/Home/

chromium-security/ssca.

Tomasulo, R. M. (1967). An efﬁcient algorithm for exploit-

ing multiple arithmetic units. IBM Journal of research

and Development, 11(1), 25–33.

Tur, J. (2020). Consider porting inter-

locked.speculationbarrier() from .net 4.8

https://github.com/dotnet/runtime/issues/31639.

Viet H Intel (2020). Spectre mitigations in intel c++

compiler https://community.intel.com/t5/Intel-

C-Compiler/Spectre-mitigations-in-Intel-C-

compiler/m-p/1227014.

Wagner, L. (2018). Mitigations landing for new class of

timing attack https://blog.mozilla.org/security/2018/

01/03/mitigations-landing-new-class-timing-attack/.

Yan, M., Choi, J., Skarlatos, D., Morrison, A., Fletcher,

C. W., & Torrellas, J. (2018). InvisiSpec: Making

Speculative Execution Invisible in the Cache Hierar-

chy. In MICRO.

Attack

PLs

C++ (GCC)

C++ (MS)

C++ (Intel)

C++ (LLVM)

C (GCC)

C (MS)

C (Intel)

C (LLVM)

Rust (LLVM)

Kotlin

Swift (LLVM)

Groovy

Objective-C

(LLVM)

Haskell (GHC)

OCaml (ocamlopt)

Dart

Java (OracleJDK)

Java (OpenJDK)

Java (GraalVM)

JavaScript

(SpiderMonkey)

JavaScript (V8)

JavaScript

(Chakra)

TypeScript

CoffeeScript

Python (PyPy)

Scala

Elixir

Clojure

Python (CPython)

OCaml

(ocamlc/ocamlrun)

Emacs Lisp

Ruby (MRI)

PHP

Shell (Bash)

Perl

PowerShell

(pwsh)

TSQL

Lua

Vim script

Source of attack

Depends on setting ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ - ∗ - - ∗ - - - - - ∗ ∗ ∗ ∗ - - - - - - - - - - - - - - - - - -

CPU

i7-2630QM - ✓ - - - ✓ - - - - ✓ - ✓ - - ✓ - - ✓ ✓ ✓ - - - - - - - ✓ - ✓ - - - - - - ✓ - - - -

i5-6200U - ✓ - ✓ ✓ ✓ - ✓ ✓ - ✓ - ✓ - ✓ ✓ - - ✓ ✓ ✓ - - - - - - - ✓ - ✓ - - - - - - - - ✓ - -

i7-6700K - - - - - - - - - - - ✓ - - - - ✓ ✓ - - - - - - - - ✓ - - ✓ - ✓ ✓ ✓ ✓ ✓ ✓ - - - ✓ ✓

Xeon Silver 4208 - - - - - - - - - - - - - - - - - - - - - - - - - - - ✓ - - - - - - - - - - ✓ - - -

Ubuntu 20.4 LTS - ✓ - ✓ ✓ ✓ - ✓ ✓ - ✓ ✓ ✓ - ✓ ✓ ✓ ✓ ✓ ✓ ✓ - - - - - ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓

Environment

gcc 9.3.0 - ✓ - - - ✓ - - - - - - - - ✓ - - - - - - - - - - - - - - - - - - - - - - - - - - -

IntelCompiler 2021.1.2 - - - ✓ - - - ✓ - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

clang 12.0.0 - - - - ✓ - - - ✓ - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

kotlinc-jvm 1.4.20 (JRE 11.0.9.1) - - - - - - - - - - ✓ - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

Swift 5.3.1 - - - - - - - - - - - ✓ - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

Groovy 3.0.4 - - - - - - - - - - - - ✓ - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

GHC 8.6.5 - - - - - - - - - - - - - - - ✓ - - - - - - - - - - - - - - - - - - - - - - - - - -

ocamlopt 4.08.1 - - - - - - - - - - - - - - - - ✓ - - - - - - - - - - - - - - - - - - - - - - - - -

Dart SDK version: 2.10.5 (stable) - - - - - - - - - - - - - - - - - ✓ - - - - - - - - - - - - - - - - - - - - - - - -

JAVA 11.0.9 - - - - - - - - - - - - - - - - - - ✓ ✓ - - - - - - - - - - - - - - - - - - - - - -

GRAALVM 20.3.0 - - - - - - - - - - - - - - - - - - - - ✓ - - - - - - - - - - - - - - - - - - - - -

PyPy 7.3.1 - - - - - - - - - - - - - - - - - - - - - - - - - - ✓ - - - - - - - - - - - - - - -

.Net Core (dotnet) 5.0.100 - - - - - - - - - - - - - - - - - - - - - - - - - - - ✓ - - - - - - - - - - - - - -

Scala 2.13.4 - - - - - - - - - - - - - - - - - - - - - - - - - - - - ✓ - - - - - - - - - - - - -

Elixir - IEx 1.9.1 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - ✓ - - - - - - - - - - - -

Clojure 1.10.1 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - ✓ - - - - - - - - - - -

CPython 3.8.2 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - ✓ - - - - - - - - - -

ocamlc/ocamlrun 4.08.1 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - ✓ - - - - - - - - -

GNU Emacs 26.3 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - ✓ - - - - - - - -

ruby 2.7.0 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - ✓ - - - - - - -

PHP 7.4.3 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - ✓ - - - - - -

bash 5.0.17(1)-release - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - ✓ - - - - -

perl v5.30.0 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - ✓ - - - -

PowerShell 7.1.0 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - ✓ - - -

SQL Server Command Line Tool Version 17.6 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - ✓ - -

Lua 5.4.1 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - ✓ -

vim 8.1-2269 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - ✓

APPENDIX

A EXPERIMENT SETUP

The table below summarizes the programming lan-

guages and their compilers/interpreters and the CPU,

operating system, and the execution environment

which we used for our experiments. The ﬁrst row

(source of attack) shows if we have performed the

attack ( ), we have not tried but other have done it

( ), we were not able to perform the attack ( ). The

next row (depends on settings) shows if compilers/in-

terpreters are not vulnerable (∗) or are vulnerable (-)

if the existing best practices for them are followed.

A checkmark (✓) shows that it was used for an ex-

periment while a dash (-) indicates that the respective

language was not tested on this CPU or OS. For the

execution environment, the dash (-) indicates that it

does not apply to the respective language and compil-

er/interpreter.

Systematic Analysis of Programming Languages and Their Execution Environments for Spectre Attacks