Systematic Analysis of Programming Languages and Their

Execution Environments for Spectre Attacks

Amir Naseredini1,3 , Stefan Gast2,3 , Martin Schwarzl3 , Pedro Miguel Sousa Bernardo4 , Amel Smajic3 ,
Claudio Canella3 , Martin Berger1,5 , Daniel Gruss2 ,3
1
University of Sussex, United Kingdom
2
Lamarr Security Research, Austria
3
Graz University of Technology, Austria
4
Instituto Superior Técnico, Universidade de Lisboa, Portugal
5
Turing Core, Huawei 2012 Labs, London, UK

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 environments 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 envi-
ronments that were previously not known to be affected. Our results highlight some programming
languages that are used to implement security-critical code, but remain entirely unprotected, even
three years after the discovery of Spectre.

1 INTRODUCTION and then rolls back the architectural state, but

not the microarchitectural state. The gadget con-
sists of a sequence of instructions, guarded by a
In conditional branch instructions, deciding conditional branch, that encodes a secret from
whether to branch or not requires evaluating the the victim’s own address space into the microar-
branch condition, which can depend on a slow chitectural state, e.g., into the cache by making
operation, such as main memory access. In most cache lines cached or not. This encoded infor-
programs, branches are highly predictable from mation remains accessible to attackers after the
information available before the branch condition misprediction is rolled back by the CPU.
has been evaluated, primarily past outcome of re-
lated conditional branches. This predictability
is exploited using branch predictors, adaptively Spectre attacks have so far been demon-
trained as the CPU executes, on past branch- strated in JavaScript [Kocher et al., 2019], native
ing behavior, see [Mittal, 2018] for an overview. code [Kocher et al., 2019, Canella et al., 2019],
Branch prediction allows CPUs to execute the Go [Duete, 2018] and Rust [Chládek, 2020]. Con-
predicted direction of the branch long before the sequently, a vast variety of mitigations have
result of evaluating the branch condition is avail- been proposed, and some of them have been de-
able. If the prediction is wrong, the execution of ployed in practice. While Meltdown attacks are
the predicted branch is rolled back, and the other mainly mitigated in hardware or microcode, Spec-
branch is executed. Note that only the architec- tre attacks mainly rely on mitigations on the
tural state is rolled back, but not the microarchi- operating-system level, or in compilers and JIT
tectural state, which remains visible in contem- engines. Given the large number of mitigations
porary CPUs. Spectre exploits the mismatch be- and programming languages with associated exe-
tween architectural and microarchitectural state cution environments, it has become unclear which
by mistraining branch predictors, so victim code programming languages, interpreters, compilers
(called gadget) executes a mispredicted branch and JIT engines, have working mitigations today
and can securely be used to implement security- To demonstrate the concrete security impact
critical code, and which do not. of our results, we present two case studies that
exploit security libraries using Spectre attacks.
Spectre does not necessarily work in every sin- First, we attack the Alice crypto library, imple-
gle execution environment. The possibility of be- mented in Java using the OpenJDK compiler. We
ing able to pull off the attack depends on several demonstrate that we can leak the secret key used
factors including (but not limited to) the runtime by Alice for encryption purposes by exploiting a
environment, whether it is fast enough (e.g., in- Spectre gadget in it. Second, we attack cryptokit,
terpreters might be too slow for the attack to be implemented in OCaml using the ocamlopt native
pulled off), the compiler and the transformations compiler. In this case study, we show that by ex-
that it enforces on the code such as optimizations ploiting a Spectre gadget, we can leak secret data
(e.g., whether it emits the code that is efficient while it resides in memory.
enough for this purpose), or the language and
its constructs (e.g., do branch-predicted code se- Our work shows that there are still several
quences exit on the binary level). Hence, it was critical security libraries implemented in pro-
not known which languages, compilers, and en- gramming languages suffering from the lack of
vironments need mitigations. We are the first mitigations. Security-critical code implemented
to systematically study which languages, compil- in these languages remains entirely unprotected
ers, and execution environments need mitigations against Spectre-type attacks, even three years af-
against Spectre attacks. The result of this study ter the discovery of the issue. We responsibly
helps developers of languages, compilers, and en- disclosed our findings to the corresponding ven-
vironments to find out whether or not they should dors and worked with them on solutions. How-
implement mitigations. ever, we emphasize that this problem goes be-
yond these specific libraries and is a problem that
In this paper, we systematically analyze the must be solved by the corresponding compiler,
security against Spectre attacks, of the top 30 runtime, or interpreter. Finally, until mitigations
most-popular programming languages, which in- are available in compilers and runtime environ-
volves an analysis of 42 compilers and execution ments, developers should be cautious using these
environments. We categorize the languages and programming languages for security-critical code,
their execution environments into three different and users should also be alert using security ap-
categories: interpreted, compiled, and managed plications implemented in such languages.
languages. We determine for each of these lan-
guages, compilers and runtimes, whether Spectre
mitigations exist and are implemented. The basis
Contributions. Our contributions are:
of this analysis is publicly available documenta-
tion and direct communication with developers. 1. A systematic analysis of the security of pro-
We discover that only 16 of the analyzed execu- gramming languages and their execution envi-
tion environments have mitigations for at least ronments with respect to Spectre attacks.
one Spectre variant. Based on this initial anal- 2. We introduce Speconnector, a novel tool to
ysis, we perform a full-scale analysis of the ex- evaluate and exploit Spectre gadgets indepen-
istence of Spectre gadgets for each of these lan- dent of the programming language.
guages and environments. To facilitate our anal- 3. We demonstrate the security impact with two
ysis, we present a novel method and tool, Specon- case studies of security-related libraries, and
nector. Speconnector allows us to evaluate and show that we can leak secrets from them.
exploit Spectre gadgets independent of the pro-
gramming language to validate leakage without
bi-directional interaction. We use Speconnector
to develop Spectre proof-of-concept attacks for 16 Outline. Section 2 provides background. Sec-
programming languages, half of which were previ- tion 3 systematically analyzes programming lan-
ously not known to be affected. Our results high- guages for Spectre mitigations. Section 4 presents
light that programming languages and their exe- our new tool Speconnector and our threat model.
cution environments used to implement security- Section 5 presents our systematic analysis of
critical code remain entirely unprotected, even the Spectre susceptibility of environments using
three years after the discovery of the issue, and Speconnector. Section 6 presents two case studies
still continue to leak secrets. showcasing our results. We conclude in Section 7.
2 BACKGROUND 1 if (x < length_of_data) {
2 tmp &= lookup_table[data[x] << 12];
In this section, we provide background on spec- 3 }
ulative and transient execution with a focus on
Spectre-type attacks, as well as interpreted, com- Figure 1: An example of an index gadget.
piled, and managed programming languages.
[Ge et al., 2016], but sometimes among logical
Speculative Execution. Because programs cores [Maisuradze and Rossow, 2018]. Therefore,
contain conditional branching, CPUs often do the CPU learns only from previous branches ex-
not know which instruction needs to be executed ecuted on the same physical core.
next. This occurs, for instance, when the out-of-
order execution reaches a not yet completed con- Transient-Execution Attacks. While spec-
ditional branch instruction which determines con- ulative and out-of-order execution signifi-
trol flow. With speculative execution, the CPU cantly increase the performance of CPUs
can save the current register state, predict the [Tomasulo, 1967], these features also have a
most likely outcome based on similar events in significant impact on the security of software
the past, and speculatively execute in the pre- running on the CPU. So-called transient-
dicted direction. Once the predicted branch in- execution attacks [Canella et al., 2019] have
struction has completed execution and the cor- demonstrated that the effects of transient
rect path is known, the CPU can decide what instructions can be reconstructed on the archi-
to do with the speculatively executed instruc- tectural level as the microarchitectural effects
tions. In the case of a correct prediction, the are not reverted. To bring the effects to the
CPU simply commits (retires) the instructions in architectural level, these types of attacks leverage
the order of the instruction stream, making the traditional side-channel attacks, e.g., cache at-
results visible on the architectural level. How- tacks. While the cache has been predominantly
ever, if the prediction is not correct, the CPU exploited for the transmission of the secret
rolls back to the saved register state, discards the data [Kocher et al., 2019, Canella et al., 2019,
result of the wrongly executed instructions, and Maisuradze and Rossow, 2018,
continues with the execution of the correct path. Koruyeh et al., 2018], other channels have
The discarded instructions are commonly re- also been shown to be effective, e.g., execution
ferred to as transient instructions [Kocher, 1996, port contention [Bhattacharyya et al., 2019].
Lipp et al., 2018, Canella et al., 2019]. While the Kocher et al. [Kocher et al., 2019]
architectural state is rolled back in the case of a first discussed transient-execution attacks
wrong prediction, the microarchitectural state is [Canella et al., 2019] using speculative execution
not reverted, hence allows to infer results and side and demonstrated that conditional branches
effects of the transiently executed instructions. and indirect jumps are potential elements to be
To make such predictions and maximize exploited to leak data. Subsequent work has then
the performance, CPUs utilize the Branch shown that the idea can be extended to func-
Prediction Unit (BPU), which consists of dif- tion returns [Maisuradze and Rossow, 2018,
ferent prediction mechanisms [Mittal, 2018]. Koruyeh et al., 2018] and store-to-load
One such prediction mechanism is the afore- forwarding [Horn, 2018]. Canella et al.
mentioned conditional branch prediction [Canella et al., 2019] then systematically an-
which is done by the Pattern History Table alyzed the field and demonstrated that the
(PHT) [Canella et al., 2019]. Other mecha- necessary mistraining can be done in the same
nisms predict conditional and indirect jump and a different address space due to some
targets [Kocher, 1996] or return addresses predictors being shared across hyperthreads.
of functions [Maisuradze and Rossow, 2018, Additionally, they showed that many of the pro-
Koruyeh et al., 2018]. Indirect jumps are pre- posed countermeasures are ineffective and do not
dicted by the Branch Target Buffer (BTB) correctly target the root cause of the problem.
[Lee et al., 2017, Evtyushkin et al., 2016, More recent work [Canella et al., 2020a] has
Kocher et al., 2019], returns by the Return Stack then analyzed the commonalities of these attacks
Buffer (RSB) [Maisuradze and Rossow, 2018, instead of the differences [Canella et al., 2019].
Koruyeh et al., 2018]. To mitigate all these attacks, various
Branch-prediction logic, e.g., BTB and RSB, proposals have been made by industry and
is typically not shared across physical cores academia. Canella et al. [Canella et al., 2020b]
analyzed the differences between counter- timizing compiler framework. C and C++ are
measures from academia and industry, high- examples of programming languages that are usu-
lighting that academia proposes more radical ally executed by compilation, although, in princi-
countermeasures compared to industry. Pro- ple, they can also be interpreted. An advantage
posed mitigations either require hardware of interpreted languages is that they are more
changes [Kiriansky et al., 2018, Yan et al., 2018, portable as only the interpreter is platform spe-
Khasawneh et al., 2019], secret annota- cific, which does not hold for compiled languages.
tion [Schwarz et al., 2020, Palit et al., 2019, As the interpreter needs to hold more information
Fustos et al., 2019], new data dependen- about the run-time state of the application, inter-
cies [Oleksenko et al., 2018, Carruth, 2018b], preted applications typically require more mem-
or reduced timer accuracy [Pizlo, 2018, ory during execution than compiled applications.
Chromium Project, 2018, Wagner, 2018]. Perl is an example of a languages that is usually
Gadgets. In transient-execution attacks, a gad- interpreted and not compiled.
get is a piece of code used to transfer the secret Hybrid compilers seek to combine the advan-
information from the victim’s side into a covert tages of compiled and interpreted languages. We
channel from which the attacker can then retrieve distinguish several variants of hybrid compilers:
it. Kocher et al. [Kocher et al., 2019] introduced Figure 2 shows the two common variants. In
the first Spectre gadget, which is shown in Fig- the first variant, a compiler first translates the
ure 1. In such a gadget, secret information is code into platform-independent code, allowing for
stored in memory following the array data. A more sophisticated optimizations, as well as al-
global variable tmp is used to prevent optimizing lowing for portability. When running the ap-
out the memory access. The attacker controls the plication, an interpreter executes this platform-
value of x, which allows mistraining the branch independent code. An example of such a hybrid
for the length check, i.e., the attacker first sup- compiler is Ocaml when using ocamlc and ocaml-
plies values for x that are lower than length of - run: ocamlc carries out the first part to com-
data. After mistraining the branch, the attacker pile the code implemented by the developer, and
supplies a larger value, accesses the secret during then ocamlrun interprets the code generated by
transient execution, and encodes it in lookup ta- ocamlc. In the second variant, the compiler again
ble, which is shared between victim and attacker. generates platform-independent code. In the sec-
From there, the attacker reads using a cache at- ond phase, the JIT-compiler uses the platform-
tack. Canella et al. [Canella et al., 2020a] refer independent code to produce the executable code
to such a gadget as an index gadget. which is interpreted by the interpreter. The inter-
preter then provides feedback to the JIT-compiler
Compiled vs Interpreted vs Managed Pro- on how to improve the generated code. An exam-
gram Execution. An important distinction in ple of such hybrid compilers are OracleJDK and
program execution is between interpretation and C# .NET. Figure 2 provides an illustration of all
compilation. The difference is in whether the pro- four aforementioned cases.
gram is executed directly 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 re- 3 SPECTRE MITIGATIONS BY
sulting file of the compilation is again interpreted, LANGUAGE AND RUNTIME
combining the other two approaches. We refer
to this as managed program execution. We often When it comes to mitigating Spectre-type at-
speak of execution environment to mean any of tacks, compilers and interpreters play a crucial
compilers, interpreters, or their hybrids. role as they generate the code that is exploited
All of these approaches to execute a program later on. In this section, we investigate different
have different advantages and disadvantages. For compilers and interpreters to determine whether
instance, compiled languages only incur the over- they provide methods to mitigate such attacks.
head of translating the code once, while inter- Our systematic analysis considers 42 different ex-
preted languages need to translate it every time ecution environments which are used to translate
they are being run. Hence, compilers can per- the top 30 most-popular programming languages
form more sophisticated optimizations as the time according to GitHub in the third quarter of 2020.
needed for translation is less important. LLVM The languages encompass compiled, interpreted,
[Lattner and Adve, 2004] is an example of an op- and managed languages.
the 8 interpreters that do not provide any public Managed Languages. Table 3 shows the results
information. Unfortunately, this step did not pro- of our analysis of 13 programming languages and
vide any additional insights. Hence, to complete their 18 respective hybrid compilers. This anal-
our investigation, we contacted the developers of ysis provides several interesting insights. For in-
the respective interpreters to ask for information stance, except for the JavaScript compilers Spi-
about potentially implemented mitigations. derMonkey [Wagner, 2018, de Mooij, 2019], V8
In this step, the developers of Perl confirmed [Chromium Project, 2018, Mcilroy et al., 2019],
that their interpreter does indeed not contain any Chakra [Microsoft, 2018], and the Java compiler
mitigations for any variant of Spectre 1 . For Ruby GraalVM [Oracle, 2020], none of the other com-
(MRI) and PHP, we unfortunately were not able pilers for managed languages provide any form
to discuss the issue with the developers. Never- of public documentation of mitigations against
theless, our results gathered in the first two steps at least one of the Spectre variants discussed by
show that we are not aware of any mitigation in Canella et al. [Canella et al., 2020a]. The first
these two interpreters. Our analysis for inter- three mitigate Spectre-PHT and Spectre-BTB
preters illustrates that it is unclear for 7 of the while GraalVM only has mitigations for Spectre-
9 analyzed interpreters if they have mitigations PHT. Similar to the previous case, we again ob-
implemented to mitigate Spectre attacks serve that the compilers that do have mitigations,
all mitigate Spectre-PHT. While we were able
Compiled Languages. Our analysis of compiled to find documentation regarding Spectre for the
programming languages shows a different result Java compiler OpenJDK, the documentation in-
compared to the analysis of interpreters. In this dicates that no mitigations are available.
analysis, we used the same approach as for the To counteract the lack of publicly available in-
interpreted languages and their interpreters, i.e., formation on mitigations, we contacted the devel-
searched public documentation, analyzed com- opers of the PyPy, C#, Scala, Elixir and OCaml
mits, and contacted the developers. (ocamlc/ocamlrun) compilers to gather informa-
Table 2 presents the results of our analysis. tion on whether they provide mitigations. In all
The results show that 13 of the 15 considered 5 cases, this discussion showed that none of them
compilers provide information about Spectre, but contain any mitigations. In addition, the docu-
only 12 of them claim to have implemented mit- mentation for OracleJDK [Oracle, 2021] is hint-
igations for at least one of the existing variants. ing at Spectre mitigations, however, it is unclear
While all 12 provide mitigations against Spectre- if any mitigation is implemented and which Spec-
PHT, only 10 provide mitigations for Spectre- tre variants are the targets in the potential miti-
BTB. Interestingly, only Go provides a mitigation gations. Unfortunately, the status of the remain-
for Spectre-RSB, while none of the compilers doc- ing 7 compilers from this category remain unclear
ument mitigations against Spectre-STL. In a con- as we did not receive a response. These 7 compil-
versation, the developers of Microsoft’s C/C++ ers are Dart, TypeScript, CoffeeScript, Clojure,
compiler confirmed that, despite missing docu- CPython, Groovy and Kotlin.
mentation, their compiler provides a Spectre-STL
mitigation. The developers of ocamlopt also con-
firmed in direct communication that their com- 4 Speconnector
piler does not provide any form of mitigation
against any Spectre variant. Unfortunately, we This part describes the goal, tasks, and advan-
were not able to get any information about the ex- tages of the Speconnector tool. Speconnector is
istence of mitigations for the two remaining com- written in C, but works for any target language.30
pilers, i.e., DM and Haskell (GHC).
The goal of Speconnector is to determine, eas-
Based on our analysis, the Go compiler has the ily and independent from the target language,
best situation regarding its mitigations against whether a given execution environment is vulner-
Spectre variants as it contains mitigations for 3 of able to Spectre.
the 4 Spectre variants discussed by Canella et al.
[Canella et al., 2020a]. 23
Maciej Fijalkowski confirmed this via email
26
Eric Meadows-Jönsson confirmed this via email
1 28
Dan Book confirmed this via email Ilya Pleskunin confirmed this via email
9 29
Shayne Hiet-Block from Microsoft confirmed this Paul King confirmed this via email
30
via email We plan to open source the tool.
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 devel-
opers ( ), not available based on the communication with developers ( ), or it was unclear whether there are
any mitigations available ( ).

C
e-
M) iv

t)
) l
LV ct

HC el

op
ca l
LV t
)

(o am
(L st

(L if

(L bje

(G sk

ml
el

M)

el

M)

M)

M)
(G ++

(M +

(I ++

(L +
)

)
PLs

OC
C+

C+

Ru

Sw

Ha
CC

S)

nt

LV

CC

S)

nt

LV

LV
C

O
Go

DM
(G

(M

(I

(L
Attack
3 5 8 10 12 5 8 10 12 12 12 12 14
Spectre-PHT
3 6 9 10 13 6 9 10 13 13 13 13 14
Spectre-BTB
3 7 9 11 7 9 11 14
Spectre-RSB
4 9 11 9 11 14
Spectre-STL

3 6 10 13
[Munday, 2020] [Lu, 2018] [Jiang, 2018] [Carruth, 2018a]
4 7 11 14
[Randall, 2020] [Biener, 2018] [Viet H Intel, 2020] [Bacarella, 2020]
5 8 12
[GCC.GNU.ORG, 2020] [Pardoe, 2018] [Carruth, 2020]

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 ( ).

n)
ru
8) Sc y)

(P yth ipt

in ml
Ja Mon t

pt

Ty ) t
(V va ke
r p

pt
a p
(O ava K)

tl ca
de ri

r
ri

kr ri

ri

Sc
J K)

OC n)
J JD

Ja M)

Ko /o
pi Sc

yP on

Py n
e
ha Sc

o
Sc

ee

ur

vy
ca l
D

o
ir
e

c
(S va

(C th
(O ava

(G ava

(C va

(o am
nJ

y)

th
a
cl

al

ml
pe

ff

oj

oo
rt

al

ix
PLs

Py
Ja
pe
ra

ra

P
Co

Cl

Gr
J
Da

C#

Sc

El
Attack
15 16 17 18 ,19 20 22 23 24 25 26 27 28 29
Spectre-PHT
15 16 18 ,19 20 ,21 22 23 24 25 26 27 28 29
Spectre-BTB
15 16 23 24 25 26 27 28 29
Spectre-RSB
15 16 21 23 24 25 26 27 28 29
Spectre-STL

15 19 24
[Oracle, 2021] [de Mooij, 2019] [Tur, 2020]
16 20 25
[Gross, 2019] [Chromium Project, 2018] [Malak and nilskp, 2018]
17 21 27
[Oracle, 2020] [Mcilroy et al., 2019] [Bacarella, 2020]
18 22
[Wagner, 2018] [Microsoft, 2018]

Threat Model. One of the main tasks of Speconnector is to

Speconnector demonstrates that an attack is establish shared memory between itself and the
possible under a regular Spectre attack threat victim application. Hence, the target applica-
model: The attacker is a co-located program run- tion first allocates 256 pages of memory and fills
ning under the same operating system and is able it with a known magic value while Speconnector
to execute arbitrary code on the victim machine. also allocates the same amount of memory in its
The victim code has an interface that we can in- own address space, i.e., the lookup table. Then,
teract with, e.g., a local API or local server can Speconnector uses the /proc/[pid]/mem file of
be a potential target code. Whether an attack is the victim to scan for the pages that contain
possible under this threat model only depends on the magic value. Once it finds them, Specon-
whether the victim leaks. Therefore, we focus on nector uses the the publicly available PTEditor
the illegal data leakage and use Speconnector to [Schwarz et al., 2018] to set the victim pages page
measure and evaluate the victim leakage. While frame numbers to the page frame numbers of its
this shows that an attack is possible, crafting a own lookup table, to establish shared memory be-
concrete end-to-end exploit for each language re- tween the two processes. As a result, any vic-
quires further engineering steps. tim access to one of the now shared pages re-
sults in a cache hit when Speconnector performs
Algorithm.
Flush+Reload to distinguish between cached and completeness, we performed the experiments on
uncached memory. the execution environments listed, even if they
The advantage of this approach is simplicity: were very similar, e.g., the both were using JVM
instead re-implementing cache attacks in all pro- in their compilation. The reasoning behind this,
gramming languages, we can rely on a well under- is that the construct of each language in its ex-
stood primitive written in C, e.g., Flush+Reload. ecution environment should be protected against
For the analysis, the only part that needs to be different Spectre variants as well as the composi-
done in the victim is to implement a victim gad- tion of different constructs, as certain mitigations,
get and to allocate 256 pages and fill them with e.g., for Spectre-PHT, can only be implemented
the known magic value. 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
5 ATTACK FEASIBILITY BY outlined categories of interpreted, compiled, and
managed languages individually.
LANGUAGE AND RUNTIME
Interpreted Languages. Using the approach
In this section, we present the results of using discussed, we evaluate all our interpreted lan-
Speconnector to determine whether we can es- guages. During this analysis, we were able to ex-
tablish a covert channel and exploit speculative ploit Perl’s interpreter, successfully demonstrat-
execution in our set of selected programming lan- ing a covert channel and leaking data using a
guages and their execution environments. To Spectre attack. The Perl interpreter does not pro-
investigate the potential vulnerabilities, we first vide any mitigations (cf. Section 3), making it
evaluate each compiler/interpreter to determine infeasible to protect an application against such
whether we can establish a covert channel. Such attacks. Out of the 9 interpreters we analyzed (cf.
a covert channel is a necessary building block for Table 4), only the Perl interpreter was vulnerable
Spectre attacks as it gives the attacker the capa- to both establishing a covert channel and a Spec-
bility of bringing secret data from the microarchi- tre attack. A potential explanation is that the
tectural state to the architectural level. To deter- speculation window might have been too small for
mine whether we can establish a covert channel, the other interpreters to fit the attack in it. In
Speconnector establishes shared memory between the remaining 8 interpreters, we were still able to
itself and the victim application. The victim establish a cache covert channel in 5 of them even
then accesses the shared lookup table in a known though we were not able to exploit them with a
pattern which Speconnector tries to reconstruct. Spectre attack. We were not able to establish a
If Speconnector cannot reconstruct the pattern, covert channel in TSQL, Shell (bash) and Vim
then it is not possible to establish a covert chan- script. However, this does not mean that these
nel. One potential reason for that can be that the interpreters are safe against Spectre attacks nor
target language uses a different memory layout against establishing a covert channel. In total, we
than C. Then, we evaluate each compiler/inter- were able to establish a covert channel in 67 % and
preter to determine whether we can exploit spec- exploit 11 % of the analyzed interpreters.
ulative execution by adding a gadget, mistrain- Compiled Languages. In our analysis of covert
ing the victim, and using Speconnector to leak channels in compiled languages, we were able to
the victim’s secret data. Because of the nature establish a covert channel in 14 out of 15 (93 %) of
of the vulnerability and the attack, while a pos- the analyzed combinations of languages and com-
itive result for an execution environment in the pilers. 12 out of the 15 (80 %) compilers generate
experiments shows that the corresponding execu- code that is vulnerable against a Spectre attack.
tion environment is vulnerable and exploitable, a This includes languages and compilers that have
negative result does not guarantee the absence of been known to be vulnerable but also ones that
the vulnerability nor the exploitability. have so far not been analyzed. One example for
The experiments were run using different ma- such a never before analyzed language and com-
chines for different programming languages and piler is OCaml with the ocamlopt compiler where
their execution environments. We listed the we were able to demonstrate both a covert chan-
CPU, the operating system, and the execution nel and a Spectre attack. While we were able to
environment version for each language and its establish a covert channel in Swift (LLVM) and
compiler/interpreter in Table 5 in Appendix A. Haskell (GHC), we were not able to exploit them
Table 4 shows the results of our analysis. For using a Spectre attack. Compilers annotated with
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 first row (depends on settings) shows if compilers/in-
terpreters are not vulnerable (⋆) or are vulnerable (-) if the existing best practices for them are followed.

(ocamlc/ocamlrun)
OCaml (ocamlopt)

Java (OracleJDK)

Python (CPython)
JavaScript (V8)
Java (OpenJDK)
Java (GraalVM)

(SpiderMonkey)
Haskell (GHC)

Python (PyPy)
Swift (LLVM)

CoffeeScript

Shell (Bash)
C++ (Intel)

Rust (LLVM)

Objective-C
C++ (LLVM)

JavaScript

JavaScript

TypeScript

Emacs Lisp
Ruby (MRI)

PowerShell

Vim script
C++ (GCC)

C (Intel)
C++ (MS)

C (LLVM)

(Chakra)
C (GCC)

Clojure
C (MS)

(LLVM)

Elixir

Kotlin
Groovy

(pwsh)
Scala

OCaml
Dart

Perl

TSQL
PHP

Lua
PLs
Go

DM

C#
Attack
Depends on setting ⋆ ⋆ ⋆ ⋆ ⋆ ⋆ ⋆ ⋆ ⋆ ⋆ ⋆ - ⋆ - - - - - ⋆ ⋆ ⋆ ⋆ - - - - - - - - - - - - - - - - - - - -
Covert Channel ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✗ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✗ ✓ ✓ ✗✓ ✗
Spectre Attack ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✗ ✗ ✓ ✗ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✗ ✓ ✓ ✗ ✗ ✗ ✓ ✓ ✓ ✗ ✗ ✗ ✗ ✓ ✗ ✗ ✗ ✗

a * in Table 4 are not exploitable or at least less strate how a Spectre attack can be used to leak
vulnerable in case the available mitigations are secret information from real-world libraries. Fur-
used and best practices are followed. thermore, we argue that a mitigation at the com-
piler level prevents our attacks.
Managed Languages. For managed languages,
we were able to demonstrate a functioning covert
channel in all 18 cases (100 %). Out of the 18 lan- 6.1 Alice - Java
guage and compiler combinations, we were able
to demonstrate a Spectre attack in 14 (78 %) In our first case study, we investigate Alice 8 , a
of them. This includes Dart, Java, C#, Scala crypto library written in Java which provides en-
Groovy, Kotlin and OCaml (ocamlc/ocamlrun), cryption/decryption with AES of byte arrays and
which were so far not known to be vulnerable, files. Alice supports different key sizes, block
i.e., no Spectre attack on these has been demon- modes and padding schemes. Our goal is to find
strated before. Similar as to compiled languages, and exploit speculative execution vulnerabilities
there are several instances, again marked with a to leak the secret key which is being used to en-
* in Table 4, where the usage of the available mit- crypt/decrypt the plaintext in Alice encryption
igations and following the best practices removes and decryption methods.
or at least reduces the impact of the vulnerability. We first performed an in-depth assessment of
Our investigation of all three language cate- this library and the way that it should be used.
gories provides several interesting insights. First, The library contains three main Java classes.
contrary to interpreted and compiled languages, Class Alice which is the main API in the li-
we were able to establish a covert channel in brary for encryption purposes. Class AliceCon-
all analyzed managed languages and compilers, text which provides the context to be passed to
while in the others there was at least one where class Alice to create a new object of it. And class
we were not able to establish a covert channel. AliceContextBuilder which is used to build the
Second, compilers for compiled languages are the context. More information about Alice library is
most vulnerable to Spectre attacks if mitigations provided on their publicly available documents.
are not used and best practices are not followed. Our attack uses three Java classes, Main, Enc
Third, in all three categories, we were able to and Victim. The Main class is responsible for
extract data using a Spectre attack in at least starting two threads on the same physical core,
one instance. This further highlights that many one uses Enc while the other uses Victim. Enc
languages and their respective compilers/inter- creates an instance of an unmodified Alice and
preters have not considered Spectre attacks even performs the encryption using the context gen-
3 years after they were introduced to the public. erated by AliceContextBuilder and the password
stored within Enc. Our Victim class contains an
index gadget (cf. Figure 1) mistrained and used
by the attacker to leak the secret information.
6 CASE STUDIES As a first step in our attack, our Main class
starts both the encryption and the victim con-
In this section, we present two case studies, each taining the gadget. Once this is done, we use
using one of the vulnerable programming lan-
8
guages taken from Table 4. For both, we demon- https://rockaport.github.io/alice/
Speconnector (cf. Section 4) simply to ease the tion that uses it leaks the sensitive data pro-
exploitation, but note that extracting the data is cessed by the library by executing a gadget while
also possible directly in Java. Speconnector es- this data is directly used or parts of it remain in
tablishes a shared memory with the victim by memory. For example, cryptokit has a function
allocating 256 pages and filling them with the transform_string t s, which applies the given
known magic value. The victim is mistrained transform object t to the given string s. The
to perform the speculative out-of-bounds access transform object itself describes the desired cryp-
which causes a secret-dependent cache access on tographic action, including its parameters. For
our shared memory. To extract the password AES encryption, these include the key and the
stored in Enc, Speconnector constantly performs initialization vector (IV). After the transforma-
Flush+Reload on the memory shared with the tion, the internal state of the transform object t
victim. As OpenJDK does not contain any Spec- is wiped, but this does not include the key and
tre mitigations (cf. Table 3), Speconnector can the IV. Furthermore, the string s is not wiped,
successfully extract the password, compromising either. The reason is that, in OCaml, strings are
the whole encryption system. passed by reference across function calls. This
makes it unsafe for the library function to over-
6.2 cryptokit - OCaml write these strings as the calling code might still
need them. Therefore, the application itself is re-
sponsible for wiping the key, the IV and the plain-
Our second case study performs a thorough anal- text. However, it is worth noting that a direct
ysis of cryptokit [Leroy, 2020], a widely used hint about this is missing in the current documen-
OCaml crypto library. As Tables 2 and 3 show, tation (version 1.16.1) of the library [Leroy, 2020]
the documentation of OCaml already indicates even though it offers a function wipe_string s
that no mitigations are available against Spectre for this purpose. Furthermore, the official OCaml
attacks. It is an important case study, as so far documentation even states that strings should be
OCaml has not been shown to be affected. treated as being immutable and advises against
In this analysis, we encountered several factors overwriting them [Leroy et al., 2020].
that complicate the analysis. First, OCaml can
be either compiled into native machine code using To verify and substantiate this finding, we
the ocamlopt compiler, or it can be compiled into performed the following experiment. Follow-
bytecode using the ocamlc compiler, which is then ing a best-practice example of using cryptokit,
executed by the ocamlrun runtime. Depending on we wrote a proof-of-concept application that en-
the compiler being used, it can either be regarded crypts user-provided plaintext. Similar to the
as a compiled or a managed language. Second, Java case study in the previous section, we al-
the environment is important as well since some locate 256 contiguous pages using OCaml’s Ar-
gadgets show themselves only in some particu- ray1 module and fill them with the known magic
lar configurations. For example, while we could value. Then we add a Spectre gadget to the ap-
not cause any data leakage with our Spectre in- plication. Using that gadget to perform specula-
dex gadget when using the ocamlc bytecode com- tive out-of-bounds accesses on a string and con-
piler and the ocamlrun runtime on an older In- necting Speconnector to it, we were able to suc-
tel Core2Duo T9600 CPU, the exact same gad- cessfully reconstruct the original plaintext after
get worked well when run on a more modern In- encrypting it and after the last reference to the
tel Core I7-6700K CPU. When compiled to na- plaintext went out of scope. To find the actual lo-
tive code using the ocamlopt compiler, the same cation of the plaintext in memory, we computed
source code produces a gadget that works on both the required offset for the out-of-bounds access
machines. For best reproducibility, we therefore in the proof-of-concept application itself. This
only used the ocamlopt native compiler in the fol- showed that the offset is the same each time the
lowing case study. program is run, making it predictable for the at-
The cryptokit library implements a variety tacker. Obtaining the key or the IV instead of
of cryptographic primitives for use in security- the plaintext should also be possible using the
sensitive applications, including symmetric-key same approach. By this, we show that an OCaml
ciphers, public-key cryptography, and hash func- application can leak sensitive data via transient
tions. Our manual analysis has not shown an execution side-channels as long as that data is in
exploitable Spectre gadget within the library it- memory. As neither the native compiler (ocam-
self, but the possibility exists that the applica- lopt) nor the bytecode compiler (ocamlopt) and
runtime (ocamlrun) provide any form of mitiga- are susceptible to Spectre attacks. Our results in-
tions, it is the task of the application developer to dicate that it is necessary to do more research into
ensure that no Spectre gadget is executed while mitigations that target a wide range of program-
sensitive data resides in memory. To wipe sensi- ming languages and execution environments.
tive data from memory, the programmer has to
overwrite strings which are otherwise considered
to be immutable by the language. REFERENCES
Furthermore, sensitive data can also remain
in internal input or output buffers, which can- [Bacarella, 2020] Bacarella, M. (2020). Spectre miti-
not be overwritten by the application developer. gations in ocaml compiler?!
For example, to read files, OCaml uses channel [Bhattacharyya et al., 2019] Bhattacharyya, A.,
objects, which are buffered [OCAML.ORG, 2021] Sandulescu, A., Neugschwandt ner, M., Sorniotti,
yet provide no means of wiping that buffer A., Falsafi, B., Payer, M., and Kurmus, A. (2019).
[Leroy et al., 2020]. We verified that sensitive SMoTherSpectre: exploiting speculative execution
data can indeed be leaked from such buffers by through port contention. In CCS.
modifying our experiment to leak the data di- [Biener, 2018] Biener, R. (2018). GCC 7.3 released.
rectly from the input buffer of the standard in- [Canella et al., 2020a] Canella, C., Khasawneh,
put channel. Again, we computed the offset for K. N., and Gruss, D. (2020a). The Evolution of
the out-of-bounds access in the victim. We ob- Transient-Execution Attacks. In GLSVLSI.
served that Address Space Layout Randomiza- [Canella et al., 2020b] Canella, C., Pudukotai Di-
tion (ASLR) leads to different offsets each time nakarrao, S. M., Gruss, D., and Khasawneh, K. N.
the program is run, because the channel buffer (2020b). Evolution of Defenses against Transient-
is stored in another memory mapping than the Execution Attacks. In GLSVLSI.
OCaml strings. However, the offset of the buffer [Canella et al., 2019] Canella, C., Van Bulck, J.,
within its memory mapping itself is constant. Schwarz, M., Lipp, M., von Berg, B., Ortner, P.,
Turning off ASLR results in a constant offset be- Piessens, F., Evtyushkin, D., and Gruss, D. (2019).
tween the OCaml string and the channel buffer. A Systematic Evaluation of Transient Execution
In conclusion, sensitive data might live longer Attacks and Defenses. In USENIX Security Sym-
posium. Extended classification tree and PoCs at
in memory than the developer might expect and, https://transient.fail/.
therefore, also be susceptible to Spectre attacks
for quite a long time. Hence, it is imperative that [Carruth, 2018a] Carruth, C. (2018a).
OCaml provides ways for a developer to either [Carruth, 2018b] Carruth, C. (2018b). RFC: Specu-
reliably remove data from sensitive buffers or to lative Load Hardening (a Spectre variant #1 miti-
hinder transient execution at all. gation).
[Carruth, 2020] Carruth, C. (2020). Speculative load
hardening.
7 CONCLUSION [Chládek, 2020] Chládek, J. (2020). rust-spectre.
[Chromium Project, 2018] Chromium Project
(2018). Mitigating Side-Channel Attacks.
We presented a systematic analysis of different
programming languages and their respective com- [de Mooij, 2019] de Mooij, J. (2019). [Meta] Spectre
pilers/interpreters against Spectre attacks. Our JIT mitigations.
analysis uncovered Spectre attacks in 16 differ- [Duete, 2018] Duete, L. (2018). spectre-go.
ent programming languages with 8 of them not [Evtyushkin et al., 2016] Evtyushkin, D., Pono-
investigated so far and not known to be vulner- marev, D., and Abu-Ghazaleh, N. (2016). Jump
able. We also demonstrated practical proof-of- over ASLR: Attacking branch predictors to bypass
concept attacks and evaluated their applicability ASLR. In MICRO.
to these programming languages and their respec- [Fustos et al., 2019] Fustos, J., Farshchi, F., and
tive execution environments. With Speconnector, Yun, H. (2019). SpectreGuard: An Efficient Data-
we presented a novel approach and tool that can centric Defense Mechanism against Spectre At-
be used to quickly verify whether a programming tacks. In DAC.
language and execution environment is vulnera- [GCC.GNU.ORG, 2020] GCC.GNU.ORG (2020).
ble to Spectre attacks. We further presented two Other built-in functions provided by gcc.
case studies of real world libraries in two different [Ge et al., 2016] Ge, Q., Yarom, Y., Cock, D., and
programming languages, demonstrating that they Heiser, G. (2016). A Survey of Microarchitectural
 Timing Attacks and Countermeasures on Contem- [Malak and nilskp, 2018] Malak, M. and nilskp
porary Hardware. Journal of Cryptographic Engi- (2018). Meltdown/spectre.
neering. [Mcilroy et al., 2019] Mcilroy, R., Sevcik, J., Tebbi,
[Gross, 2019] Gross, A. (2019). Java and speculative T., Titzer, B. L., and Verwaest, T. (2019). Spectre
execution vulnerabilities. is here to stay: An analysis of side-channels and
[Horn, 2018] Horn, J. (2018). speculative execution, speculative execution. arXiv:1902.05178.
variant 4: speculative store bypass. [Microsoft, 2018] Microsoft (2018). Mitigating spec-
[Jiang, 2018] Jiang, J. L. (2018). Using intel® ulative execution side-channel attacks in Microsoft
compilers to mitigate speculative execution side- Edge and Internet Explorer.
channel issues. [Mittal, 2018] Mittal, S. (2018). A Survey of
[Khasawneh et al., 2019] Khasawneh, K. N., Ko- Techniques for Dynamic Branch Prediction.
ruyeh, E. M., Song, C., Evtyushkin, D., Pono- arxiv:1804.00261.
marev, D., and Abu-Ghazaleh, N. (2019). Safe- [Munday, 2020] Munday, M. (2020). consider extend-
Spec: Banishing the Spectre of a Meltdown with ing ’-spectre’ option to other architectures.
Leakage-Free Speculation. In DAC.
[Kiriansky et al., 2018] Kiriansky, V., Lebedev, I., [OCAML.ORG, 2021] OCAML.ORG (2021). File
Amarasinghe, S., Devadas, S., and Emer, J. (2018). manipulation.
DAWG: A Defense Against Cache Timing Attacks [Oleksenko et al., 2018] Oleksenko, O., Trach, B.,
in Speculative Execution Processors. In MICRO. Reiher, T., Silberstein, M., and Fetzer, C. (2018).
[Kocher et al., 2019] Kocher, P., Horn, J., Fogh, A., You Shall Not Bypass: Employing data de-
Genkin, D., Gruss, D., Haas, W., Hamburg, M., pendencies to prevent Bounds Check Bypass.
Lipp, M., Mangard, S., Prescher, T., Schwarz, M., arXiv:1805.08506.
and Yarom, Y. (2019). Spectre Attacks: Exploiting [Oracle, 2020] Oracle (2020). Oracle graalvm enter-
Speculative Execution. In S&P. prise edition 20 guide.
[Kocher, 1996] Kocher, P. C. (1996). Timing Attacks [Oracle, 2021] Oracle (2021). Oracle JVM Security
on Implementations of Diffe-Hellman, RSA, DSS, Enhancements.
and Other Systems. In CRYPTO.
[Palit et al., 2019] Palit, T., Monrose, F., and Poly-
[Koruyeh et al., 2018] Koruyeh, E. M., Khasawneh, chronakis, M. (2019). Mitigating data leakage by
K., Song, C., and Abu-Ghazaleh, N. (2018). Spec- protecting memory-resident sensitive data. In AC-
tre Returns! Speculation Attacks using the Return SAC.
Stack Buffer. In WOOT.
[Pardoe, 2018] Pardoe, A. (2018). Spectre mitiga-
[Lattner and Adve, 2004] Lattner, C. and Adve, tions in msvc.
V. S. (2004). LLVM: A compilation framework
for lifelong program analysis & transformation. In [Pizlo, 2018] Pizlo, F. (2018). What Spectre and
IEEE / ACM International Symposium on Code Meltdown mean for WebKit.
Generation and Optimization – CGO. [Randall, 2020] Randall, K. (2020). consider extend-
[Lee et al., 2017] Lee, S., Shih, M., Gera, P., Kim, ing ’-spectre’ option to other architectures.
T., Kim, H., and Peinado, M. (2017). Inferring [Schwarz et al., 2018] Schwarz, M., Lipp, M., and
Fine-grained Control Flow Inside SGX Enclaves Canella, C. (2018). misc0110/PTEditor: A small
with Branch Shadowing. In USENIX Security library to modify all page-table levels of all pro-
Symposium. cesses from user space for x86 64 and ARMv8.
[Leroy, 2020] Leroy, X. (2020). cryptokit/cryp-
tokit.mli at release1161. [Schwarz et al., 2020] Schwarz, M., Lipp, M.,
Canella, C., Schilling, R., Kargl, F., and Gruss,
[Leroy et al., 2020] Leroy, X., Doligez, D., Frisch, A., D. (2020). ConTExT: A Generic Approach for
Garrigue, J., Rémy, D., and Vouillon, J. (2020). Mitigating Spectre. In NDSS.
The OCaml system release 4.11 – Documentation
and user’s manual. [support, 2020] support, M. (2020). Kb4073225 - sql
server guidance to protect against spectre, melt-
[Lipp et al., 2018] Lipp, M., Schwarz, M., Gruss, D., down and micro-architectural data sampling vul-
Prescher, T., Haas, W., Fogh, A., Horn, J., Man- nerabilities.
gard, S., Kocher, P., Genkin, D., Yarom, Y., and
Hamburg, M. (2018). Meltdown: Reading Kernel [Tomasulo, 1967] Tomasulo, R. M. (1967). An effi-
Memory from User Space. In USENIX Security cient algorithm for exploiting multiple arithmetic
Symposium. units. IBM Journal of research and Development,
11(1):25–33.
[Lu, 2018] Lu, H. (2018). x86: Cve-2017-5715, aka
spectre. [Tur, 2020] Tur, J. (2020). Consider porting inter-
[Maisuradze and Rossow, 2018] Maisuradze, G. and locked.speculationbarrier() from .net 4.8.
Rossow, C. (2018). ret2spec: Speculative Execu- [Viet H Intel, 2020] Viet H Intel (2020). Spectre
tion Using Return Stack Buffers. In CCS. mitigations in intel c++ compiler.
[Wagner, 2018] Wagner, L. (2018). Mitigations land-
ing for new class of timing attack.
[Yan et al., 2018] Yan, M., Choi, J., Skarlatos, D.,
Morrison, A., Fletcher, C. W., and Torrellas, J.
(2018). InvisiSpec: Making Speculative Execution
Invisible in the Cache Hierarchy. In MICRO.
A EXPERIMENT SETUP
Table 5 summarizes the setups of our experiments.
Table 5: Programming languages and their compilers/interpreters and the CPU, operating system, and the
execution environment which we used for our experiments. The first 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/interpreters are not vulnerable (⋆) or are vulnerable
(-) if the existing best practices for them are followed. A checkmark (✓) shows that it was used for an experiment
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 compiler/interpreter.

(ocamlc/ocamlrun)
OCaml (ocamlopt)

Java (OracleJDK)

Python (CPython)
JavaScript (V8)
Java (OpenJDK)
Java (GraalVM)

(SpiderMonkey)
Haskell (GHC)

Python (PyPy)
Swift (LLVM)

CoffeeScript

Shell (Bash)
C++ (Intel)

Rust (LLVM)

Objective-C
C++ (LLVM)

JavaScript

JavaScript

TypeScript

Emacs Lisp
Ruby (MRI)

PowerShell

Vim script
C++ (GCC)

C (Intel)
C++ (MS)

C (LLVM)

(Chakra)
C (GCC)

Clojure
C (MS)

Kotlin

Groovy

(LLVM)

Elixir

(pwsh)
Scala

OCaml
Dart

Perl

TSQL
PHP

Lua
PLs
Go

DM

C#
Attack
Source of attack
Depends on setting ⋆ ⋆ ⋆ ⋆ ⋆ ⋆ ⋆ ⋆ ⋆ ⋆ - ⋆ - - ⋆ - - - - - ⋆ ⋆ ⋆ ⋆ - - - - - - - - - - - - - - - - - -
i7-2630QM - ✓ - - - ✓ - - - - ✓ - ✓ - - ✓ - - ✓✓✓ - - - - - - - ✓ - ✓ - - - - - - ✓ - - - -
CPU

i5-6200U - ✓ - ✓ ✓ ✓ - ✓ ✓ - ✓ - ✓ - ✓ ✓ - - ✓✓✓ - - - - - - - ✓ - ✓ - - - - - - - - ✓ - -
i7-6700K - - - - - - - - - - - ✓ - - - - ✓✓ - - - - - - - - ✓ - - ✓ - ✓ ✓ ✓ ✓✓✓ - - - ✓✓
Xeon Silver 4208 - - - - - - - - - - - - - - - - - - - - - - - - - - - ✓ - - - - - - - - - - ✓ - - -
Ubuntu 20.4 LTS - ✓ - ✓ ✓ ✓ - ✓ ✓ - ✓ ✓ ✓ - ✓ ✓✓✓✓✓✓ - - - - - ✓ ✓✓✓ ✓ ✓ ✓ ✓ ✓✓✓✓ ✓ ✓✓✓
OS

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 - - - - - - - - - - - - - - - - - - - - ✓ - - - - - - - - - - - - - - - - - - - - -
Environment

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 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - ✓