979-8-3503-4099-0/23/$31.00  2023 IEEE

s: They Are Not There Until They Are Triggered

Akshita Reddy Mavurapu
University of New Hampshire

Haoqi Shan

Xiaolong Guo
University of Kansas

Orlando Arias
University of Massachusetts, Lowell

Dean Sullivan
University of New Hampshire

The hardware security community has made significant advances in detecting Hardware Trojan vulnerabilities using software fuzzing-inspired automated analysis. However, the Electronic Design Automation (EDA) code base itself remains under-examined by the same techniques. Our experiments in fuzzing EDA tools demonstrate that, indeed, they are prone to software bugs.
As a consequence, this paper unveils  attacks, a new hardware attack that does not generate harmful hardware, but rather, exploits software vulnerabilities in the EDA tools themselves. A key feature of  attacks is that they are capable of deploying a malicious payload on the system hosting the EDA tools without triggering verification tools because  attacks do not rely on superfluous or malicious hardware that would otherwise be noticeable.
The aim of a  attack is to execute arbitrary code on the system on which the vulnerable EDA tool is hosted, thereby establishing a permanent presence and providing a beachhead for intrusion into that system. Our analysis reveals 83% of the EDA tools analyzed have exploitable bugs. In what follows, we demonstrate an end-to-end attack and provide analysis on the existing capabilities of fuzzers to find  attacks in order to emphasize their practicality and the need to secure EDA tools against them.

§ INTRODUCTION

Recently, significant effort in the hardware security community has been paid to the automated analysis of Hardware Trojan vulnerability detection [1, 2] by borrowing concepts from software fuzzing. Less attention, however,
has been paid in applying those same concepts to the analysis of the EDA code base itself. EDA tools are complex and sophisticated pieces of software comprising millions of lines of code (MLoC) and heavily used in the community. Moreover, there is a clear correlation between the number of lines of code, third-party library reliance, and number of users for a tool on the one hand and the number of errors and reported vulnerabilities on the other [3, 4]. This insight is, in part, what led us to ask if we can we expect that the EDA tool itself is bug free.

Our results indicate that, similar to other existing complex code bases, EDA tools contain buggy code. We evaluate a representative set of common EDA tools and found an exploitable bug in 83% of tools analyzed, other instances of bugs that may be exploitable given a motivated attacker with enough time, and still other instances of bugs that, while not fully exploitable for a full system compromise, can be used as means of rendering the tool unusable (Denial of Service).

In this paper we present a new class of hardware attacks called s. To begin, we consider these hardware attacks because the malicious input is embedded in hardware-related components such as a hardware descrption language (HDL), simulation test vectors, and waveforms. As such, we are using “hardware" in the broad sense to include anything typically involved in the EDA toolchain and hardware manufacturing life cycle. While we say throughout the paper that, for instance, the HDL in a  is malicious, it is not inherently so as it does not generate any malicious or superfluous hardware.
Instead, as shown in Figure <ref>, a  aims to exploit vulnerabilities only on buggy EDA tools to deploy a malicious payload in the system running the tool in order to compromise it. This duality property is the inspiration behind the name.

Borrowing from the famous double slit experiment, a  projected onto an EDA tool exhibits benign properties if the EDA tool is safe, but is malicious if the EDA tool is vulnerable.

The goal of a  attack is to gain arbitrary code execution on the machine hosting the vulnerable EDA tool. This, in itself, typically the first step for an attacker who wishes to obtain persistence as in a supply-chain attack [5].
For ethical considerations, in this work we do not show the precise steps to achieve a full system compromise. We do, however, use this as justification to show how a  can be a significant threat to organizations and companies by presenting how a full -based attack can be developed. Further, we consider s relevant for two additional reasons.

First,  attacks represent a new attack vector to the hardware security community. We do not claim that triggering software vulnerabilities to gain arbitrary code execution is new, but rather, that targeting software vulnerabilities in EDA tools via maliciously crafted inputs is new. Concern in the hardware security community is typically focused on preventing and/or detecting maliciously crafted HDL that attempts to embed a traditional Hardware Trojan. Little attention, if any, has been paid to the EDA tools themselves[Recent work explored attacks stemming from malicious EDA tools but focused on their ability, in such a scenario, to surreptitiously embed hardware Trojans [6]. More will be said regarding this, and other, related works in Section <ref>.]. We show that this should be a concern. Further, it is an unexplored attack surface by virtue of its newness. To the best of our knowledge, this is the first paper to report an end-to-end attack targeting an EDA tool.

Second, s can be practically exploited in a variety of relevant scenarios. We will present the details of an end-to-end attack in Section <ref>. As shown in Figure <ref>, at a high-level, we reason that an attacker can leverage the HDL design, development, and integration process. The first relies on the complexity of HDL designs. For instance, we found we can hide the offending input in a large design, with MLoC, that will unlikely be analyzed line-by-line. Furthermore, by their nature, s do not generate malicious or superfluous hardware and thus go undetected by verification tools. The second scenario makes use of the need to guard intellectual property (IP) by releasing it to third-party vendors [7]. In such a scenario, it is trivial to embed a maliciously crafted input which can exploit vulnerabilities in EDA tools. The third scenario exploits shared computing environments. FPGA resources are currently scant and expensive. It is not uncommon to turn to cloud providers who offer/lease relatively cheap FPGA resources to users in a hosted environment as an alternative. This allows the attack to arbitrarily upload[Within reason and as prescribed by the cloud vendors rules [8].] malicious input to a cloud-hosted EDA tool.

§.§ Motivation

We aim to address several motivating points in introducing  attacks that we hope will further aid its understanding:

How did we discover  attacks?
We were inspired by recent efforts that have demonstrated significant results from the automated analysis of HDL
using software fuzzing techniques. However, it is not our aim to improve those results, but rather, to query the EDA tools themselves by treating them purely as pieces of software. For instance, an EDA tool accepts HDL as input for synthesis and a combination of HDL and test vector input during simulation. In each case, we are interested in finding vulnerabilities in the way the EDA tool handles those inputs when guided by a mutational fuzzer.

Why do we target synthesis, simulation, and scripting? Generally, EDA tools take an HDL design and perform synthesis and place-and-route to generate a bitstream that can then be used to configure an FPGA, or alternatively target a technology library to generate an ASIC design. Simulation is performed prior to place-and-route and uses a testbench as a wrapper to handle the flow of input and output to/from the design under test. These two cases allow us to mutate input either in the form of synthesizable HDL or as a test vector input. We also target traditional EDA tool scripting languages because they often act as a front-end to automate the design flow from synthesis to place-and-route, or other types of

§.§ Contributions

To summarize, our contributions include:

* We present  attacks, a unique hardware attack that is benign if the EDA tool is bug-free but malicious if it is not.

* We highlight the practicality of  attacks by presenting an end-to-end exploit for an EDA tool.

* We present analysis of the effectiveness of fuzzing EDA tools in the discovery of  attacks.

In what follows, we will first introduce relevant background in Section <ref> before discussing related works in Section <ref>. We then present an end-to-end  in Section <ref>. Analysis of the use of fuzzing to find s is presented in Section <ref> prior to a discussion of future work and conclusions in Section <ref>.

vsheet/.style =
text width=0.75in,
minimum height=1in,
text centered,

[shift=(0.1in, 0.1in)]
[thick, fill=white] (-0.375in, -0.5in) – ++(0.75in, 0)
– ++(0, 0.9in) – ++(-0.1in, 0.1in)
– ++(-0.65in, 0) – cycle
(0.375in, 0.4in) -| ++(-0.1in, 0.1in);

[thick, fill=white] (-0.375in, -0.5in) – ++(0.75in, 0)
– ++(0, 0.9in) – ++(-0.1in, 0.1in)
– ++(-0.65in, 0) – cycle
(0.375in, 0.4in) -| ++(-0.1in, 0.1in);
in 1,...,5
[very thin, gray!50] (-0.275in, 0.15in*-0.5in) – ++ (0.55in, 0);

[vsheet] at(0, 0) (verilog) HDL;

[shift=(1.75in, 0in)]
[thick] (-0.375in, -0.375in) rectangle ++(0.75in, 0.75in);
in 0,1
[draw, double arrow, fill=white, minimum height=0.05in, text width=0.25in, rotate=90]
at(0.375in * -0.1875in, 0.375in) ;
[draw, double arrow, fill=white, minimum height=0.05in, text width=0.25in, rotate=90]
at(0.375in * -0.1875in, -0.375in) ;

[vsheet, minimum height=0.75in] (ip)
at(0, 0) IP Core;

[shift=(3.75in, 0.75in)]
[color=black, fill=gray, rounded corners=1]
(-1.375, 1.125) rectangle (1.375, -0.875);
[color=black, fill=white, rounded corners=1]
(-1.125, 0.875) rectangle (1.125, -0.625);
[color=black, fill=gray, rounded corners=1]
(-0.25, -0.875) – (-0.5, -1.125) – (0.5, -1.125) – (0.25, -0.875) – cycle;
[font=, color=red!45] at(0, 0.125) ;
[font=, text width=2.75cm, minimum height=2.25cm, text centered] at(0, 0.125) (sim) SIM;

[shift=(3.75in, -0.75in)]
[color=black, fill=gray, rounded corners=1]
(-1.375, 1.125) rectangle (1.375, -0.875);
[color=black, fill=white, rounded corners=1]
(-1.125, 0.875) rectangle (1.125, -0.625);
[color=black, fill=gray, rounded corners=1]
(-0.25, -0.875) – (-0.5, -1.125) – (0.5, -1.125) – (0.25, -0.875) – cycle;
[font=, color=red!45] at(0, 0.1) ;
[font=,text width=2.75cm, minimum height=2.25cm, text centered] at(0, 0.125) (synth) SYNTH;

[shift=(5.75in, 0)]
[thick, rounded corners=0.25cm]
(-1, -1) rectangle (1, 1);
[gray, rounded corners=0.2cm]
(-0.85, -0.85) rectangle (0.85, 0.85);
in 1,2,3,4
(2*/5 - 4/5 - 2/10, -1) – ++(0, -0.5);
(2*/5 - 4/5 - 2/10,  1) – ++(0,  0.5);
( 1, 2*/5 - 4/5 - 2/10) – ++(0.5,  0);
(-1, 2*/5 - 4/5 - 2/10) – ++(-0.5, 0);

[thin, gray, -o] (0.4, -0.85) – ++(0, 0.85);
[thin, gray] (0.6, -0.85) – ++(0, 0.425);
[thin, gray] (0.2, -0.85) – ++(0, 0.425);
[thin, gray, -*] (0.85, 0.2) -| ++(-1.2, -0.4);
[thin, gray, -*] (-0.85, -0.4) – ++(0.85, 0);
[thin, gray, -o] (-0.85,  0.4) – ++(1, 0);
(die) at (-1.5, 0);

[-latex'] ($ (verilog.east) + (0.2in, 0) $) –
node[anchor=north] package ( $ (ip.west) - (0.1in, 0) $ );

[latex'-latex'] ( $(sim.south) - (0, 0.1in)$) –
node[anchor=west, text width=4em, text centered] design & integrate

[-latex'] let 1=(ip.east) in let 2=(sim.west) in let 3=(synth.west) in
(1 + 0.1in, 1) -| ((1 + 2)/2, 2) – (2 - 0.1in, 2);
[-latex'] let 1=(ip.east) in let 2=(sim.west) in let 3=(synth.west) in
((1 + 3)/2 + 0.75em, 1) node[rotate=90] license
((1 + 3)/2, 1) |- (3 - 0.1in, 3);

[-latex] let 1=(sim.east) in let 2=(die) in let 3=(synth.east) in
(3 + 0.1in, 3) -| ((3 + 2)/2, 2)
((3 + 2)/2 - 0.75em, 2) node[rotate=90] fabricate
(1 + 0.1in, 1) -| ((1 + 2)/2, 2) – (2 - 0.1in, 2);

The  makes use of standard HDL workflows in the industry. Malicious HDL is packed as part of an IP core. This HDL does not aim to generate malicious hardware. Instead, it triggers and exploits bugs in an HDL synthesis or simulation tool in order to comprome the system where the tool runs. If fabricated, ICs including  affected IP cores do not exhibit malicious behavior.

§ BACKGROUND

§.§ EDA Tools

We evaluate 6 EDA tools in total including two synthesis tools ( [9],  [10]), three simulation tools ( [11],  [12], and  [13]), and a formal analysis tool ( [14]). It is assumed that the readers are familiar with these tools, so we forego a detailed explanation of their functionality and internals. Instead, we provide a high-level overview of them in Table <ref> and refer the reader to their source for further information.

Open-source EDA tools analyzed in this work.

EDA Tool     Description

iverilog     A verilog HDL compiler for the IEEE-1364 standard

gtkwave     A GTK+ based wave viewer

yosys     Open source synthesis suite for Verilog

abc     A synthesis and verification suite

z3     An SMT solver developed by Microsoft

verilator     A verilog HDL simulator

We focus our evaluation on open source EDA tools because they are easily obtained at no cost and are supportive of bug reporting. We have reported our results to the tool maintainers. However, they are still in the patching process so, in this paper, we limit our discussion to number of bugs found and type. We remove all details of the EDA tool, insofar as possible, in the end-to-end exploit to abide with responsible disclosure procedures.

§.§ Fuzzing

Fuzzing is one of the most successfully employed techniques for software bug discovery [15] and currently an active area of research in both the hardware and software communities. Fuzzers are usually categorized as black-box, white-box, or grey-box depending on the amount of information they have of the underlying program. A black-box fuzzer knows nothing about the internal structure of the program, whereas a white-box fuzzer knows everything about the program's internal structure. A grey-box fuzzer sits in-between the two in that it has limited knowledge of the internals of the program behavior via coverage-guided feedback provided by some form of program instrumentation.

In this paper, we rely heavily on coverage-guided fuzzing. Briefly, the fundamental steps taken in coverage guided fuzzing include:

* Instrumentation: The program being fuzzed is augmented with code to record its control-flow during execution.

* Seed pool Generation: The fuzzer generates candidate inputs for the program, which can either be user supplied or randomly generated. The correct generation of an initial seed pool is an active area of research [16].

* Input mutation: After each round, selected inputs that exhibit unique code coverage are mutated (e.g. addition, deletion of bytes or flipping, rotating bits among several others).

* Coverage-guided feedback: Code coverage information is recorded as the seed inputs are executed. This information is binned, ordered, and then selected (e.g. best/new code coverage) to generate the new input corpus for the next fuzzing round.

Using open-source tools allows us to use gray-box fuzzers with little effort. Closed-source EDA tools require the use of black-box fuzzers which are slow and unreliable. Since our objective is to demonstrate the dangers of s we believe this is a fair compromise.

§ RELATED WORKS

We are unaware of any existing effort to fuzz EDA tools and craft  attacks. Project F4PGA [17, 18] aims to reverse engineer bitstreams for Lattice and Xilinx FPGAs using what amounts to fuzzing, but has a completely different goal than our work. However, we are not claiming complete ingenuity. Analysis of software using a fuzzer is common-place and likely performed in-house by EDA tool vendors, or at the very least during the development process for reporting and fixing bugs prior to release. With that said, we are only aware of one bug report [19], but there are probably many that go unreported publicly.

Recent research [20]  investigates logic synthesis tools for the correctness of their output via equivalence checking. The research is constructed around a tool, Verismith, that generates semantically correct and deterministic Verilog allowing for comparison between the generated design and its synthesized netlist. If they differ, then a bug is registered. A similar analysis is performed for high-level synthesis tools [21]. Our work, however, is not interested in the correctness of output for a given logic synthesis tool, but rather, whether a given EDA tool contains bugs that can triggered via specially crafted input to gain control of the system. We show that many such bugs can indeed be found for a variety of commonly used tools (synthesis, simulation, verification) and present an end-to-end exploit to demonstrate their impact.

An orthogonal line of research was proposed in [6, 22] that investigates the attack surface of malicious EDA tools. The authors demonstrate the potential for attacks by, for instance, making minor modifications to the intermediate files generated by the EDA toolchain. This research highlights and provides insight into the vulnerabilities that can be exploited by attackers if the EDA toolchain is compromised. An interesting approach may be to combine  attacks with this line of research to first gain control of the EDA tool in order to then embed a traditional Hardware Trojan.

§ BUILDING A

In what follows, we first introduce our adversarial model. We then discuss the steps taken to build a full end-to-end  attack chain on an EDA tool. Due to page limitations, we are limited to discussing a single attack against a given EDA tool. However, we found 12 exploitable bugs in total, see Table <ref>, in which we are able to craft end-to-end exploits across the tools outlined.

§.§ Adversarial Model and Assumptions

introduces a new class of hardware attacks where an adversary can ship an IP core written in any given HDL, a simulation test vector, or script for tool management that contains a specially crafted payload. However, unlike traditional Hardware Trojans the bundle in question does not generate any malicious hardware. Instead, the adversary's goal is to compromise the computing system of the licensee. This may be done with the purpose of spying, sabotaging operations, or stealing data. The  shipped as part of the IP core exploits a vulnerability in the tooling utilized by the victim to establish a permanent presence in their computing system. When processed by a non-vulnerable tool, the  is not triggered nor does it generate extraneous or superfluous hardware, thereby remaining hidden from detection.

§.§ Finding an Exploitable Bug

We examined the results of our fuzzing campaign on open-source EDA tools until we found a crash that was the result of an error that could be readily exploited. Suitability for exploitation was determined by examining the crash and performing a two factor test:

* whether the behavior causing the crash is controllable in ways that do not trigger a denial of service; and

* whether the behavior causing the crash allows for the corruption of memory areas containing code pointers.

A suitable vulnerability was found in tool REDACTED [We have followed responsible disclosure procedures for all vulnerabilities found and reported them to the respective maintainers. The tool name is omitted to comply with procedures.]. The vulnerability allows us to perform a write anywhere in the program's stack, which is conducive to a type of attack under the umbrella of code-reuse attacks called return-oriented programming (ROP) [23, 24].

§.§ Preparing, Deploying, and Synthesizing the HDL

For purposes of deployment the HDL can be wrapped in IEEE 1735-2023 [25] but this is not strictly necessary. The goal is not to hide a traditional Hardware Trojan which generates malicious logic, but to deploy HDL which generates legitimate hardware.
The  payload aims to exploit bugs on the EDA toolchain being used to compromise the victim's infrastructure. As such, for our purposes, the HDL can be sent in plain-text, as long as the portion of the HDL which triggers the bug in the HDL tool is innocuous.

[style=ccode,caption=Simplified view of the vulnerability.,label=lst:vulnerable_code]
char buffer[1024], * p = buffer;
va_list ap;
/* ... */
p += vsnprintf(p, buffer+sizeof(buffer)-p, fmt, ap); /* $\ding{182}$ */
p += snprintf(p, buffer+sizeof(buffer)-p, "");     /* $\ding{183}$ */

We make use of a write anywhere vulnerability we found in the implementation of the [style=ccode]f_REDACTED_r() function of one of the synthesis tools we tested. By crafting a specific payload and exploiting this vulnerability we are able to overwrite a return address in the program's stack, thereby allowing us to perform a control-flow attack. Through repeated usages of this vulnerability, we craft a payload which results in a chain of gadgets that achieve our desired result. In our case, we wish to print an innocent message in the terminal to signify a successful attack.

When synthesized, the HDL in question makes use of one of the vulnerabilities presented in Section <ref>, Table <ref>. A simplified version of the bug is shown in Listing <ref>. The code in question attempts to perform safe string concatenation through the use of the [style=ccode]snprintf() family of functions. The next available location in the buffer is found by advacing the pointer [style=ccode]p by the return of the [style=ccode]vsnprintf() function in the line labeled 182. However, it is imperative to notice that these functions do not return the value of characters added to the buffer, but the number of characters that would have been added were there enough room in the buffer. As such, on the call to [style=ccode]vsnprintf() in 183 the pointer may point to an address outside the bounds of the buffer. This gives us a spatial memory error which can be exploited to perform a write to a location of memory.

The spatial memory error in question allows us to overwrite any byte on memory to have a value of [style=ccode]0x00. Because the buffer in question is allocated in the stack of a function automatic storage variables and any code pointers stored in the stack, such as return addresses, are prime targets. Since the vulnerability in question allows us to freely move a pointer to any address in the stack area, we can safely bypass commonly deployed defenses such as stack protection [26] while constructing the desired ROP-chain. This allows us to gain arbitrary code execution by chaining gadgets (e.g. small instruction sequences) together from the existing code base.

§.§ A Word about Full System Compromise

We show how we can achieve arbitrary code execution by exploiting bugs in the synthesis environment. A system compromise relies on a payload which can cause permanent changes to the OS introducing malware. Achieving this goal further requires escalation of privileges through a kernel vulnerability. The latter are common [27, 28, 29, 30] and do not require our payload to directly exploit them. Our payload can simply launch another application (such as through the [style=ccode]execve() family of functions) which can more readily exploit such vulnerabilities.

§ ON FUZZING EDA TOOLS

Number, type, and exploitability of bugs per EDA tool.

EDA Tool

1*Z3     1*1         null pointer dereference     53

2*GTKWave     2*7
heap overflow

null pointer dereference

2*verilator     2*3
stack overflow

null pointer dereference

2*iverilog     2*11
stack overflow

null pointer dereference

1*ABC     1*9
null pointer dereference

3*Yosys     3*6
heap overflow

stack overflow

null pointer dereference

Total     37         12

$\dagger$ Number listed corresponds to unique bugs.

$\ddagger$ Indicates if a bug creates a vulnerability which can be used to perform an attack other than a Denial of Service.

Coverage plots for evaluated EDA tools.

Number of timeouts per fuzzing interval for z3

In what follows, we present a discussion on how we found bugs on each tool we examined as well as a description of the process and tooling used. We summarize the bugs found in Table <ref> as well as present an analysis of coverage achieved.

§.§ Experimental Tools

We used  [31] to fuzz each EDA tool due to its comparative performance in recent literature [32, 33]. Honggfuzz is a multi-threaded, grey-box coverage-guided fuzzer. It takes input corpora, checks them for new coverage, and then feeds the files to a simple in-memory corpus directory. It utilizes randomly chosen inputs from this memory and mutates them to start fuzzing.

We used  [34] to generate coverage information for each EDA tool. The tools are instrumented to emit profile and coverage information by compiling them with  using the  and  flags. Coverage information is generated by running the instrumented EDA tool normally. A raw profile file is created that is then converted using the  tool. Finally, a -formatted file is exported to collect the profiled edge coverage during the measured interval.

We used a combination of  [35] and  [36] to determine the uniqueness of the bugs found.
is first used to minimize the number of crashing inputs by performing crash deduplication using a heuristic that selects between file and line number and the address of the first interesting stack frame. This approach is imperfect and may lead to missing unique crashes (false negatives) but avoids labelling aliasing crashes as unique (false positives).  is then used to minimize a crashing input to its bare minimum (in terms of bytes). This allows us to more easily determine how to control the bug by modifying the minimized input.

§.§ Experiment Setup

We instrumented the source code for each EDA tool, used a trivial input seed (e.g. an appropriate “hello, world” for the tool), and applied flags where necessary to ensure proper functionality of the tool with the fuzzer (e.g. disabling  GUI) while fuzzing.
Each EDA tools was evaluated 5 times for a 24 hour period on a 24 core Intel i7-12850HX with 32 GiB of memory running Ubuntu 22.04.2 LTS for a total of 20,000 compute hours per recommendations [33].

§.§ Unique Crashes and Crash Types

Table <ref> shows the number of unique crashes, crash types, and exploitability of the crash for each EDA tool. In total, we found 37 unique crashes. Limited manual analysis was used to determine that 12 of these bugs were exploitable from userland. This does not mean that the remaining bugs are not exploitable, but rather they were not immediately exploitable given our analysis. A motivated attacker under the correct conditions could exploit the bugs.

We categorized the bugs broadly as either null-pointer dereferences, heap, or stack overflows. With respect to the latter two classes, we made no distinction between a out-of-bounds access or an overflow for  clarity. We found, however, that the heap overflows were typically write-anywhere vulnerabilities that crashed while accessing invalid memory. Of these, we found that 62% were controllable - we could read/write to an arbitrary location in mapped memory.

§.§ Evaluation of Coverage

Coverage plots for each EDA tool are provided in Figure <ref>. It is apparent from these plots that, in the majority of cases, the fuzzing campaign shows diminishing returns as it progresses in time. This can be explained, in part, as a side-effect of the method of logging coverage information. After each logging interval, the saved corpora in the default directory used by the fuzzer are removed and saved in an accumulated directory of corpora from prior intervals. This was done to avoid analyzing prior corpora for coverage information and, thereby, save time. However, we also reason that the fall-off in coverage over time is due to the highly structured input requirements for EDA tools. The initial seed, while trivially constructed for our evaluation, represents a valid starting point for the fuzzer. This can be seen by the immediate increase in line coverage. However, as time elapses, that input becomes less structured under mutation by the fuzzer. We observed that those programs which show diminishing returns experience a concomitant increase in number of timeouts. This effectively prevents the fuzzer from making forward progress during each interval of coverage evaluation.

Only one tool, , shows steady growth. Others show almost no growth after initialization. The  SMT solver performs worst in that it shows diminishing returns after only 12 hours of fuzzing. This makes sense considering its strict input requirements. We plot the number of timeouts over time for  as a topical explanation for these results in Figure <ref>. Notice that the number of timeout increases at 12 hours. We observed a similar trend for the other EDA tools too.

Percent line coverage achieved while fuzzing compared to total line coverage.

EDA Tool     12h (%)     24h (%)

iverilog     21     17

GTKWave     15     13

Yosys     11     9

ABC     15     23

Z3     13     9

verilator     8     5

We also show the achieved line coverage compared to total line coverage as a percentage in Table <ref>.
In most cases, our results indicate that the fuzzer was only capable of shallow analysis. Improving the seed corpus would perhaps improve these results per discussions in related work [16]. However, a more obvious, yet more complicated, solution would be to develop a custom interface capable of handling highly-structured input for the fuzzer.

§ FUTURE WORK AND CONCLUSIONS

There is a clear trend between a tool's code base and complexity of its user ecosystem, and the number of reported memory vulnerabilities for that tool [3, 4].  attacks exploit this trend to launch end-to-end attacks against common EDA tools. Therefore, in order to defend against them, an EDA tool vendor could eliminate all memory vulnerabilities in its code base. Research, however, suggests that its unlikely memory corruption can be completely eliminated from runtime efficient languages without paying a severe performance loss [37] or switching entirely to a memory safe language [38]. The latter is unlikely, though gaining traction, and the former untenable. Another mitigation strategy against  attacks includes code-reuse mitigations. However, these too are often imperfect or negatively impact performance [39].

Another promising strategy would be to incorporate fuzzing into the EDA tooling ecosystem. As Section <ref> demonstrated, current fuzzing infrastructure is ill-suited to handle the highly structured input requirements for the common EDA tools. An interesting area of research, partially explored in [20], includes the creation of domain-specific front-ends capable of outputting correctly formatted data. This would provide a sane mutational block with which the fuzzer can work. This would not only resolve the diminishing returns observed during our experimentation, but also allow deeper exploration of the code base with respect to coverage.

To conclude, in this paper we introduced a new class of Hardware Trojan which we call s. Unlike traditional hardware attacks, s do not generate spurious or malicious hardware but aim to exploit vulnerabilities in EDA tools to infect and establish a presence on computer systems. We caution that s can be used as vectors to enable spying, sabotaging, or stealing data of a potential rival or organization by attacking their computing infrastructure. We further showcase how, with some effort, s can be developed to target a wide array of EDA tools. Although in this work we focus on open-source tools, commercial closed-source tools are likely not bug-free and vulnerable to the same types of attack. We hope that this work raises awareness of this attack vector and jolts the industry into better securing their tools.

[1]
R. Kande, A. Crump, G. Persyn, P. Jauernig, A.-R. Sadeghi, A. Tyagi, and J. Rajendran, “$\{$TheHuzz$\}$: Instruction fuzzing of processors using $\{$Golden-Reference$\}$ models for finding $\{$Software-Exploitable$\}$ vulnerabilities,” in 31st USENIX Security Symposium (USENIX Security 22), 2022, pp. 3219–3236.

[2]
T. Trippel, K. G. Shin, A. Chernyakhovsky, G. Kelly, D. Rizzo, and M. Hicks, “Fuzzing hardware like software,” in 31st USENIX Security Symposium (USENIX Security 22), 2022, pp. 3237–3254.

[3]
C. Woody, R. Ellison, and W. Nichols, “Predicting software assurance using quality and reliability measures,” CARNEGIE-MELLON UNIV PITTSBURGH PA SOFTWARE ENGINEERING INST, Tech. Rep., 2014.

[4]
“Beware the browser within,” <https://www.infoworld.com/article/2672106/beware-the-browser-within.html>, accessed: 2022-10-23.

[5]
A. Cao and B. Dolan-Gavitt, “What the fork? finding and analyzing malware in github forks,” in Proceedings of the NDSS, vol. 22, 2022.

[6]
S. Sunkavilli, Z. Zhang, and Q. Yu, “Analysis of attack surfaces and practical attack examples in open source fpga cad tools,” in 2021 22nd International Symposium on Quality Electronic Design (ISQED).1em plus 0.5em minus 0.4emIEEE, 2021, pp. 504–509.

[7]
J. Speith, F. Schweins, M. Ender, M. Fyrbiak, A. May, and C. Paar, “How not to protect your ip–an industry-wide break of ieee 1735 implementations,” in 2022 IEEE Symposium on Security and Privacy (SP).1em plus 0.5em minus 0.4emIEEE, 2022, pp. 1656–1671.

[8]
Amazon, “Overview of aws ec2 fpga development kit,” https://github.com/aws/aws-fpga, 2023.

[9]
C. Wolf, “Yosys open synthesis suite,” 2016.

[10]
R. Brayton and A. Mishchenko, “Abc: An academic industrial-strength verification tool,” in Computer Aided Verification: 22nd International Conference, CAV 2010, Edinburgh, UK, July 15-19, 2010. Proceedings 22.1em plus 0.5em minus 0.4emSpringer, 2010, pp. 24–40.

[11]
S. Williams and M. Baxter, “Icarus verilog: open-source verilog more than a year later,” Linux Journal, vol. 2002, no. 99, p. 3, 2002.

[12]
W. Snyder, “Verilator and systemperl,” in North American SystemC Users’ Group, Design Automation Conference, 2004.

[13]
T. Bybell, “Gtkwave electronic waveform viewer,” 2010.

[14]
L. De Moura and N. Bjørner, “Z3: An efficient smt solver,” in International conference on Tools and Algorithms for the Construction and Analysis of Systems.1em plus 0.5em minus 0.4emSpringer, 2008, pp. 337–340.

[15]
H. Liang, X. Pei, X. Jia, W. Shen, and J. Zhang, “Fuzzing: State of the art,” IEEE Transactions on Reliability, vol. 67, no. 3, pp. 1199–1218, 2018.

[16]
A. Hazimeh, A. Herrera, and M. Payer, “Magma: A ground-truth fuzzing benchmark,” Proceedings of the ACM on Measurement and Analysis of Computing Systems, vol. 4, no. 3, pp. 1–29, 2020.

[17]
K. E. Murray, M. A. Elgammal, V. Betz, T. Ansell, K. Rothman, and A. Comodi, “Symbiflow and vpr: An open-source design flow for commercial and novel fpgas,” IEEE Micro, vol. 40, no. 4, pp. 49–57, 2020.

[18]
S. Kashif, T. Ahmed, M. Ismail, and F. A. Karim, “Chipshop: A cloud based gui for accelerating soc design.”

[19]
“Unsigned bit extension in if statement,” June 2019. [Online]. Available: <https://support.xilinx.com/s/question/0D52E00006iHwwSSAS/vivado-20191-unsigned-bit-extension-in-if-statement?language=en_US>

[20]
Y. Herklotz and J. Wickerson, “Finding and understanding bugs in fpga synthesis tools,” in Proceedings of the 2020 ACM/SIGDA International Symposium on Field-Programmable Gate Arrays, 2020, pp. 277–287.

[21]
Y. Herklotz, Z. Du, N. Ramanathan, and J. Wickerson, “An empirical study of the reliability of high-level synthesis tools,” in 2021 IEEE 29th Annual International Symposium on Field-Programmable Custom Computing Machines (FCCM).1em plus 0.5em minus 0.4emIEEE, 2021, pp. 219–223.

[22]
S. Sunkavilli, Z. Zhang, and Q. Yu, “Fpga security: Security threats from untrusted fpga cad toolchain,” in Frontiers of Quality Electronic Design (QED) AI, IoT and Hardware Security.1em plus 0.5em minus 0.4emSpringer, 2023, pp. 551–573.

[23]
H. Shacham, “The geometry of innocent flesh on the bone: Return-into-libc without function calls (on the x86),” in Proceedings of the 14th ACM conference on Computer and communications security, 2007, pp. 552–561.

[24]
R. Roemer, E. Buchanan, H. Shacham, and S. Savage, “Return-oriented programming: Systems, languages, and applications,” ACM Transactions on Information and System Security (TISSEC), vol. 15, no. 1, pp. 1–34, 2012.

[25]
“Ieee approved draft recommended practice for encryption and management of electronic design intellectual property (ip),” IEEE P1735/D2, May 2023, pp. 1–100, 2023.

[26]
P. Wagle, C. Cowan et al., “Stackguard: Simple stack smash protection for gcc,” in Proceedings of the GCC Developers Summit, vol. 1, 2003.

[27]
“CVE-2023-35788.” Available from MITRE, CVE-ID CVE-2023-35788., June 2023. [Online]. Available: <http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2023-35788>

[28]
“CVE-2023-3812.” Available from MITRE, CVE-ID CVE-2023-3812., July 2023. [Online]. Available: <http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2023-3812>

[29]
“CVE-2023-4004.” Available from MITRE, CVE-ID CVE-2023-4004., July 2023. [Online]. Available: <http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2023-4004>

[30]
“CVE-2023-4147.” Available from MITRE, CVE-ID CVE-2023-4147., August 2023. [Online]. Available: <http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2023-4147>

[31]
R. Swiecki, “Honggfuzz: A general-purpose, easy-to-use fuzzer with interesting analysis options,” https://github. com/google/honggfuzz, 2017.

[32]
Y. Li, S. Ji, Y. Chen, S. Liang, W.-H. Lee, Y. Chen, C. Lyu, C. Wu, R. Beyah, P. Cheng et al., “$\{$UNIFUZZ$\}$: A holistic and pragmatic $\{$Metrics-Driven$\}$ platform for evaluating fuzzers,” in 30th USENIX Security Symposium (USENIX Security 21), 2021, pp. 2777–2794.

[33]
J. Metzman, L. Szekeres, L. Simon, R. Sprabery, and A. Arya, “Fuzzbench: an open fuzzer benchmarking platform and service,” in Proceedings of the 29th ACM joint meeting on European software engineering conference and symposium on the foundations of software engineering, 2021, pp. 1393–1403.

[34]
LLVM, “llvm-cov - emit coverage information,” https://llvm.org/docs/CommandGuide/llvm-cov.html, 2023.

[35]
“Afltriage,” <https://github.com/quic/AFLTriage>, accessed: 2023-6-19.

[36]
A. Fioraldi, D. Maier, H. Eißfeldt, and M. Heuse, “$\{$AFL++$\}$: Combining incremental steps of fuzzing research,” in 14th USENIX Workshop on Offensive Technologies (WOOT 20), 2020.

[37]
L. Szekeres, M. Payer, T. Wei, and D. Song, “Sok: Eternal war in memory,” in 2013 IEEE Symposium on Security and Privacy.1em plus 0.5em minus 0.4emIEEE, 2013, pp. 48–62.

[38]
K. R. Fulton, A. Chan, D. Votipka, M. Hicks, and M. L. Mazurek, “Benefits and drawbacks of adopting a secure programming language: Rust as a case study,” in Seventeenth Symposium on Usable Privacy and Security (SOUPS 2021), 2021, pp. 597–616.

[39]
P. Larsen and A.-R. Sadeghi, The Continuing Arms Race: Code-Reuse Attacks and Defenses.1em plus 0.5em minus 0.4emAssociation for Computing Machinery and Morgan & Claypool, 2018.


# Anomaly Detection under Coordinate Transformations

Gregor Kasieczka<EMAIL_ADDRESS>Institut für
Experimentalphysik, Universität Hamburg, 22761 Hamburg, Germany  Radha
Mastandrea<EMAIL_ADDRESS>Department of Physics, University of
California, Berkeley, CA 94720, USA  Physics Division, Lawrence Berkeley
National Laboratory, Berkeley, CA 94720, USA  Vinicius Mikuni<EMAIL_ADDRESS>National Energy Research Scientific Computing Center, Berkeley Lab, Berkeley,
CA 94720, USA  Benjamin Nachman<EMAIL_ADDRESS>Physics Division, Lawrence
Berkeley National Laboratory, Berkeley, CA 94720, USA  Berkeley Institute for
Data Science, University of California, Berkeley, CA 94720, USA  Mariel Pettee
<EMAIL_ADDRESS>Physics Division, Lawrence Berkeley National Laboratory,
Berkeley, CA 94720, USA  David Shih<EMAIL_ADDRESS>New High Energy
Theory Center, Rutgers University, Piscataway, NJ 08854, USA

###### Abstract

There is a growing need for machine learning-based anomaly detection
strategies to broaden the search for Beyond-the-Standard-Model (BSM) physics
at the Large Hadron Collider (LHC) and elsewhere. The first step of any
anomaly detection approach is to specify observables and then use them to
decide on a set of anomalous events. One common choice is to select events
that have low probability density. It is a well-known fact that probability
densities are not invariant under coordinate transformations, so the
sensitivity can depend on the initial choice of coordinates. The broader
machine learning community has recently connected coordinate sensitivity with
anomaly detection and our goal is to bring awareness of this issue to the
growing high energy physics literature on anomaly detection. In addition to
analytical explanations, we provide numerical examples from simple random
variables and from the LHC Olympics Dataset that show how using probability
density as an anomaly score can lead to events being classified as anomalous
or not depending on the coordinate frame.

##  I Introduction

Given the vast parameter space of Beyond-the-Standard-Model (BSM) physics as
well as the lack of recent discoveries, there has been a growing interest in
new search techniques that reduce model dependence. A number of novel
approaches based on machine learning (ML) have been proposed that can
automatically identify anomalous regions of phase space [1, 2, 3, 4, 5, 6, 7,
8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22, 23, 24, 25, 26, 27,
28, 29, 30, 31, 32, 33, 34, 35, 36, 37, 38, 39, 40, 41, 42, 43, 44, 45, 46,
47, 48, 49, 50, 51, 52, 53, 54, 55, 56, 57, 58, 59, 60, 61, 62, 63, 64, 65,
66, 67, 68, 69, 70, 71, 72, 73, 74, 75, 76, 77, 78, 79]. These techniques can
be categorized by their BSM hypotheses, which directly relates to their ML
strategy. While most proposals do not make these hypotheses explicit, the
existing approaches typically posit one of three possibilities: (i) the BSM is
rare: $p_{B}(x)$ is small for background probability density $p_{B}$ and for
BSM data point $x$; (ii) the BSM is overdense: $p_{S}(x)/p_{B}(x)$ is large
for signal probability density $p_{S}$; (iii) the BSM is more similar to known
BSM models than to the background.

These three possibilities approximately map onto unsupervised, weakly
supervised, and semisupervised machine learning methods, respectively. All
three of these generic hypotheses are much weaker than the usual, fully
supervised case where the hypothesis is very specific and involves assuming
particular couplings, decay chains, masses, etc. The unsupervised methods
learn implicitly or explicitly the probability density $p_{B}$, and then
anomalous events are defined by those with a low density, usually through the
use of an anomaly score that is a proxy for $p_{B}$ (such as the loss function
of an autoencoder - see Sec. II.1). Weakly supervised methods learn likelihood
ratios between a target dataset and a reference (mostly anomaly-free) dataset.
Weakly supervised learning refers to learning with noisy labels – in this
context, the target dataset has a noisy label of ‘signal’ while the reference
dataset has a noisy label of ‘background’. Semisupervised methods use a number
of simulated signal models, often combined with (mostly anomaly-free) data.
This categorization is not unique and the names used here are based on their
meaning in the high energy physics (HEP) ML literature (see Ref. [80] for a
recent review). Most papers on anomaly detection for HEP fall in the
unsupervised category, although the only existing ML-based anomaly detection
physics results use weakly supervised learning [21, 45]. For this paper, we
consider only the unsupervised and weakly supervised cases, as they are the
most commonly studied for HEP analyses.

Due to the ill-posed nature of attempting to identify any anomaly, there is no
one method that will be more sensitive than all others111In the limit of
infinite statistics, flawless background estimation, and arbitrarily powerful
ML model architecture/training, weakly supervised methods can be universally
optimal. Of course, this is never true in practice; see Ref. [16], App. A..
Each approach has merits and disadvantages. For example, previous works have
explored the tradeoffs between unsupervised and weakly supervised learning
[24, 42, 37]. In particular, Ref. [42] pointed out that in the context of
resonance searches, weakly supervised methods may outperform unsupervised
methods for relatively higher signal fractions because they can explicitly use
the presence of the anomalies to guide their performance. In contrast,
unsupervised approaches are nearly independent of the presence of signal and
so can maintain performance even at low signal fraction. However, if the
signal is in the bulk of the background distribution, then unsupervised
methods may be unable to find it no matter how much signal is present.

Another core feature of anomaly detection approaches is their response to
coordinate transformations. While likelihood ratios are independent of
invertible coordinate transformations, the notion of an event being ‘rare’ is
inherently coordinate-dependent. Since unsupervised methods cannot be guided
by the presence of anomalies as in weakly supervised approaches, the selection
of observables used for anomaly detection may be more important for
unsupervised methods compared with weakly supervised approaches. The fact that
probability densities are not invariant under coordinate transformations is
well known and the connection to anomaly detection has recently been explored
in the broader machine learning community [81]. Our goal is to bring awareness
of this issue to HEP, where there are a growing number of proposals that make
use of coordinate-dependent methods. While coordinate sensitivity is relevant
for both achieving signal sensitivity and estimating the Standard Model
background, we focus entirely on the former as it is usually the focus of
recent anomaly detection proposals.

This paper is organized as follows. Section II provides a taxonomy of ML-based
anomaly detection methods. The statistical properties of coordinate
transformations of observables are described in Sec. III. Illustrative
numerical examples are given in Sec. IV, first with a simple, analytic example
and then a more realistic example based on a dijet search at the Large Hadron
Collider (LHC). The paper ends with conclusions in Sec. V.

##  II Landscape of Anomaly Detection Methods

In this section, we provide a brief summary of unsupervised and weakly
supervised anomaly detection methods. We also provide references to recent
applications of these methods in the HEP field.

###  II.1 Unsupervised

One of the most popular approaches studied in the phenomenology literature is
the autoencoder (AE). The first AE approaches [10, 6, 5] worked by
simultaneously training two neural networks: an encoder network
$f:\mathbb{R}^{N}\rightarrow\mathbb{R}^{M}$ and then a decoder network
$g:\mathbb{R}^{M}\rightarrow\mathbb{R}^{N}$. The typical loss function is the
mean squared error222Capital letters represent random variables and lower case
letters represent realizations of the random variables.:
$\langle(g(f(X))-X)^{2}\rangle$. For arbitrarily flexible networks and
training procedures, $f\circ g$ could approach the identity. To ensure this
does not happen, the network capacities and training procedure are restricted
and $M\ll N$. Anomalies are then characterised by high reconstruction loss
$(g(f(x))-x)^{2}$ compared to the background.

As with any compression algorithm, the autoencoder will maximize its
efficiency if it dedicates its limited capacity based on the probability
density of a given event. For this reason, the AE implicitly333Vanilla AEs
have a strong dependence on the ML architecture and training procedure, which
means that they may not be as precise at estimating the density as other
approaches. estimates $p_{B}(x)$. Anomaly scores based on autoencoders can
also be created to take advantage of the compressed latent space created by
the algorithm. Those are often based on Variational Autoencoders (VAEs) [82,
83] or similar methods, trained to generate a latent space with useful
statistical properties [8, 31, 32, 58, 25, 41, 43, 58, 84, 78].

Beyond VAEs, other deep generative models proposed for unsupervised anomaly
detection include Generative Adversarial Networks (GANs) [85, 86] and
Normalizing Flows [87, 88]. In all of these cases, the generative model is
implicitly (GANs and VAEs) or explicitly (Normalizing Flows (NFs)) learning
$p_{B}(x)$, so anomaly scores are directly linked to the probability density.
In the case of GANs, anomalies can be identified by combining the generative
model with an autoencoder [20] and assigning an anomaly score to the
reconstruction loss between the inputs and the generated outputs. With a
direct estimate of the density, the output of a NF can be used directly as an
anomaly score [76, 48, 79]444Normalizing Flows have also been proposed for use
as weakly supervised anomaly detection methods - see Ref. [16, 55, 89, 73].. A
detailed comparison of various generative models on benchmark BSM signals was
studied in Ref. [48].

###  II.2 Weakly Supervised

In contrast to unsupervised methods, weakly supervised approaches require two
datasets: a reference and a target. Some approaches emphasize the estimation
of the reference sample [2, 3, 15, 16, 55, 55, 73] and some approaches take
the reference sample as given [1, 4, 65, 38, 74, 90, 70]. Strategies for
determining the reference sample span a spectrum ranging from signal-model
agnostic and background-model dependent approaches using simulations to
resonance searches where sideband information can be directly used to estimate
a background-only reference. Hybrid methods have also been proposed, as in the
case of creating noisy labels for weak supervision using unsupervised
autoencoders [24].

Once the reference sample is acquired, most methods estimate the likelihood
ratio directly by training a classifier to distinguish examples from the
target and reference datasets. It is well-known that the output of a
classifier trained with a standard loss function like binary cross-entropy is
monotonically related to the likelihood ratio (see e.g. Ref. [91, 92]).
Directly estimating probability densities and taking ratios has also been
explored [16].

##  III Statistics of Coordinate Transformations

In this section, we will review some elementary facts about probability
densities and their applications to anomaly detection555Note that methods that
do not exactly learn the density like vanilla autoencoders may have additional
susceptibilities to variable transformations..

Suppose that we have initial coordinates $X\in\mathbb{R}^{N}$ and coordinate
transformation $Y=f(X)$, where $f$ is an invertible and differentiable
function666Much of the discussion also still applies if this is not true
everywhere, but the bookkeeping becomes significantly more complex, so we
focus on this case.. If a point in phase space $x$ has probability density
$p_{X}$, then the corresponding point $y=f(x)$ has probability density:

$\displaystyle p_{Y}(y)=p_{X}(f^{-1}(y))\left|\frac{d}{dy}f^{-1}(y)\right|\,,$
(1)

where the last term is the Jacobian determinant of $f^{-1}$ evaluated at $y$.
If $f$ is a linear transformation, then the Jacobian determinant is
independent of $x$. This means that if we order events by density, then the
ordering is unchanged. As an example, consider the linear function $y=ax+b$.
By the above equation, we have
$p_{Y}(y)=p_{X}(\frac{y-b}{a})\left|\frac{1}{a}\right|$. Coordinate changes of
these types produce a simple shift and rescaling of the probability
distribution $p_{X}$, as shown in Fig. 1(a). Note that this includes
standardization where the mean is subtracted and then the data are divided by
the standard deviation.

In contrast, if $f$ is non-linear, then the Jacobian determinant can depend on
$x$. As an example, the non-linear function $y=e^{-x}$ yields the probability
density $p_{Y}(y)=p_{X}(-\ln(y))\left|\frac{1}{y}\right|$, so the Jacobian
determinant is still a function of $y$ and therefore also of $x$. Since the
Jacobian determinant is non-constant, this choice of coordinate transformation
can dramatically affect the density-ranked order of events, as shown in Fig.
1: low-density values of $X$ are mapped to high-density values of $Y$.

One popular anomaly detection protocol would be to take events that are ‘rare’
in an absolute sense: $p_{X}(x)<c$ for some threshold $c$. If $c$ is fixed,
then the events selected would change under coordinate transformations due to
the Jacobian factor in Eq. 1. An alternative protocol that is more robust (but
still sensitive) to coordinate transformations would consider ‘rare’ in a
relative sense so that the Jacobian factors cancel. In particular, instead of
comparing densities to an absolute threshold, we could compare the density of
one event to the density of other events. A protocol in this direction would
be to take a fraction $q$ of the ‘rarest’ events.

For example, in one dimension, this corresponds to using a threshold $c$ given
by the $q$ quantile of the density. Symbolically, the quantile in $X$ for a
one-dimensional random variable are given by:777It may be useful to consider
both the highest and lowest quantiles, although for ordering by anomaly score,
presumably only the most anomalous events should be considered (not the
least).

$\displaystyle q$ $\displaystyle=\int_{c}^{\infty}p_{X}(x)dx\,.$ (2)

Since $c$ is now defined by an integral over a density and not a bare density,
one may hope that it is more robust to coordinate transformations. Ideally, if
we compute the threshold $c^{\prime}$ after transforming into $y=f(x)$, we
would have $f(c)=c^{\prime}$. In reality:

$\displaystyle q$ $\displaystyle=\int_{c^{\prime}}^{\infty}p_{Y}(y)dy$ (3)
$\displaystyle=\int_{c^{\prime}}^{\infty}p_{X}(f^{-1}(y))\left|\frac{d}{dy}f^{-1}(y)\right|dy$
$\displaystyle=\int_{f^{-1}(c^{\prime})}^{f^{-1}(\infty)}p_{X}(x)\left|\frac{df}{dx}\right|^{-1}\frac{df}{dx}\,dx\/.$
(4)

The features $X$ over which the quantile is computed could be the original
observables or one could first map to the anomaly score and consider the most
anomalous events. If the Jacobian in Eq. III is non-negative, then the two
penultimate terms cancel and $f^{-1}(c^{\prime})=c$, so the same events are
selected before and after the coordinate transformation. However, if the
Jacobian takes on negative values, the order of events under $f$ is reversed
and then different events can be selected ($f^{-1}(c^{\prime})\neq c$). For
example, if $f(x)=-x$, then the lowest and highest quantiles are completely
reversed. Another extreme example is when $f$ is the Cumulative Distribution
Function (CDF). In this case, $f(X)$ is uniformly distributed between $0$ and
$1$ so no point is rarer than any other.

In contrast, likelihood ratio methods are invariant under coordinate
transformations because the Jacobian determinant in Eq. 1 is the same for the
target probability density and the reference probability density (and thus
drops out in the ratio). This is strictly only true when $f$ is bijective (as
assumed above), but it may be approximately true even if this is not the case.
Note that even though likelihood ratios are formally invariant under
coordinate transformations, it may be that practical approaches benefit from a
judicial choice of coordinates. For example, observable standardization is
often essential in enabling effective ML training.

(a)

(b)

Figure 1: Histograms for a random normal variable $X$ with a (a) linear
transform $Y=2X+5$, (b) non-linear transform $Y=e^{-X}$. The shaded regions
mark where $|X|>1$. Variables that originate from low-density values of $X$
are hatched (“/” for $X<1$ and “\” for $X>1$). For the linear transformation,
low-density values of $X$ map to low-density values of $Y$. For the non-linear
transformation, however, the low-density values originating from $X>1$ are
mapped to high-density values of $Y$.

Equation 1 is a well-known fact found in textbooks of probability and
statistics. Its connection with anomaly detection was recently made by the
machine learning community [81]. In the following section, we provide an
illustrative Gaussian example and then make an explicit connection with HEP,
both using the relative threshold protocol.

##  IV Numerical Examples

###  IV.1 Analytic Case

To clearly illustrate the ideas discussed in the previous section, we will
construct a simple example to demonstrate a dramatic consequence of this
sensitivity to coordinate transformations. Let $X_{b}\sim\mathcal{N}(0,1)$
represent a set of background observables, and let $X_{s}\sim\mathcal{N}(1,1)$
represent a set of signal observables. This scenario is illustrated in Fig.
2(a). A density estimation-based search for anomalies would consist of
learning the density of the background $p_{X_{b}}$, then making a cut where
the density is low. This would designate the two tails of $X_{b}$ as rare, and
a search for anomalies would then successfully pick up the signal events
$X_{s}$ overlapping with the right-tail phase space of the background.

Now, suppose that instead of the variables $X_{b}$ and $X_{s}$, we used
$Y_{b}=f(X_{b})$ and $Y_{s}=f(X_{s})$, where $f$ is the CDF of a standard
normal random variable. This scenario is illustrated in Fig. 2(b). In this
case, $Y_{b}$ (but not $Y_{s}$) would be distributed uniformly from $0$ to
$1$. A density estimation-based anomaly detection search would then fail:
while the signal is mapped to high values under the transformation
$Y_{s}=f(X_{s})$, there are no anomalous (i.e. low-density) regions of the
background variable $Y_{b}$ that would be identified and probed for signal.

One could imagine even less optimal transformations that produce high
background densities where there are high signal densities and low background
densities where there are low (or zero) signal densities. One such scenario is
illustrated in Fig. 2(c) for the transformation
$Y_{b,s}=g(X_{b,s})=\tanh(X_{b,s}+2)$. Anomaly detection through density
estimation would fail for such a transformation of variables due to the
background distribution aligning closely with the signal distribution.

(a)

(b)

(c)

Figure 2: Histograms for the background and signal events in the Gaussian
example for (a) the nominal coordinates, (b) after the coordinate
transformation $Y=f(X)$ where $f$ is the CDF of a standard normal, and (c)
after the coordinate transformation $Y=g(X)=\tanh(X+2)$.

We also illustrate the impact of a change of coordinates when popular anomaly
detection algorithms are used to identify the anomalies. We train an
Autoencoder, a Normalizing Flow, and a weakly-supervised model based on the
Classification Without Labels (CWoLa) paradigm [93, 2, 3]. The dataset before
the change of coordinates consists of two-dimensional distributions of
background $X_{b}\sim\mathcal{N}(0,1)$ and signal $X_{s}\sim\mathcal{N}(1,1)$,
with each dimension independent and identically distributed. The two-
dimensional dataset is used to ensure the bottleneck layer of the Autoencoder
is lower dimensional than the input. The two functions used are the same ones
introduced previously: $f$, i.e. the CDF of a standard normal random variable,
and $g(x)=\tanh(x+2)$.

The Autoencoder compresses the two-dimensional data into a one-dimensional
latent space using fully-connected layers of sizes (50, 20, 10) and ReLU
activation functions before the bottleneck layer of size 1. The decoder is
simply the mirrored version of the encoder architecture. Only background
events are used during training, and the anomaly score is then defined by the
reconstruction loss. The Normalizing Flow is built using a continuous
Normalizing Flow [94] with a backbone neural network defined by two stacked
fully-connected models with layer sizes (50, 20, 10) and $\tanh$ activation.
The background-only density is estimated with anomaly score defined as minus
the probability density of a single event. Finally, the weakly-supervised
model based on CWoLa is trained using a classifier consisting of six fully-
connected layers of sizes (50, 50, 20, 20, 10, 10) and the ReLU activation
function. The model is trained to separate a reference sample of background
only events from a mixed sample of signal plus background events, with signal
events representing 10% of the overall dataset size. The anomaly score is
taken as the ratio $h(x)/(1-h(x))$, where $h(x)$ is the classifier output
after a sigmoid activation function. A summary of the anomaly detection
methods and the anomaly scores is given in Tab. 1 with the different model
architectures shown in Fig. 3. All methods are implemented using TensorFlow
[95] and Adam [96] optimizer with learning rate of 0.001 for 500 epochs or
until the validation loss, assessed using an independent dataset, does not
improve for 10 consecutive epochs.

Table 1: Choice of anomaly detection methods and anomaly scores used in this work. Algorithm | Anomaly score
---|---
Autoencoder | $(g(f(x))-x)^{2}$
Normalizing flow |  -$p_{b}(x)$
Weakly-supervised | $h(x)/(1-h(x))$
Figure 3: Network architectures used to implement the anomaly detection
methods.

We evaluate the performance for each algorithm using the Receiver Operating
Characteristic (ROC) curve for signal and background events, as shown in Fig.
4.

Figure 4: Receiver operating characteristic (ROC) curve for different anomaly
detection algorithms trained using the Gaussian dataset in the original
coordinate system (Gaussian) and after the transformations $f(x)=\Phi(x)$
(CDF) and $f(x)=\tanh(x+2)$ (tanh). The black line denotes the expected ROC
curve for a random algorithm.

Both the Autoencoder and Normalizing Flow show reasonable performance in the
Gaussian example, but both fail to identify the anomaly after the CDF change
of coordinates and even end up systematically removing signal events after the
hyperbolic tangent transformation. The weakly-supervised algorithm, on the
other hand, identifies the anomaly and shows the same performance for all
choices of coordinate systems.

###  IV.2 LHC Olympics Case

The examples in the previous section were contrived in order to demonstrate
the most extreme cases. This section uses realistic HEP observables where the
impact is not as dramatic, but the effects of coordinate transformations are
still non-negligible.

The dataset used here was originally developed for the LHC Olympics [37] and
is briefly described in the following. The background process is dijets and
the signal is $W^{\prime}\to X(\to qq)Y(\to qq)$ with $m_{W^{\prime}}=3.5$
TeV, $m_{X}=500$ GeV, and $m_{Y}=100$ GeV. All events are generated using
Pythia8 [97] and Delphes3.4.1 [98, 99, 100]. The jets are clustered using
FastJet [101] with the anti-$k_{T}$ algorithm [102] using $R=1$. Finally, all
events are required to have at least one jet with $p_{T}>1.2$ TeV.

Some important discriminating features in the LHC Olympics dataset are the
masses of the leading and subleading jets. In particular, the masses of the
leading ($m_{1}$) and subleading ($m_{2}$) jets should approximately
correspond to the masses of the $X$ and $Y$ particles for the signal. Since
the masses have a large kinematic range, they are often preprocessed by taking
the natural logarithm, $m\mapsto\log(m/\text{TeV})$ (henceforth, the units are
suppressed). Other natural examples include the $n$-subjettiness observables
$\tau_{1}$ and $\tau_{2}$ [103, 104]. These observables quantify the extent to
which a jet is more consistent with having one or two prongs. The variable
$\tau_{1}$ captures similar properties of the jet radiation pattern as the jet
mass. A researcher aiming to pre-process as minimally as possible might
attempt to do anomaly detection with $(\tau_{1},\tau_{2})$ directly, while
someone wanting to use standard pre-processing might use instead
$(\tau_{1},\tau_{2}/\tau_{1})$. The $n$-subjettiness ratio
$\tau_{21}=\tau_{2}/\tau_{1}$ is one of the most widely used taggers for
identifying two-prong substructure. This is characteristic of Lorentz-boosted
$W/Z$ boson decays, but it is also the case for our BSM particles $X$ and $Y$.
We show results for $m$ and $\log(m)$, but we found similar, although less
dramatic, results for $n$-subjettiness.

If $(m_{1},m_{2})$ is described by probability density $p$, then the
transformed coordinates are described by density
$\tilde{p}(\log(m_{1}),\log(m_{2}))=p(m_{1},m_{2})m_{1}m_{2}$. This shows that
the ordering by anomaly score can be reversed depending on the relative sizes
of $p$, $m_{1}$ and $m_{2}$.

Figure 5: A comparison of the two probability densities for the same events.
The shaded regions and the red dots indicate the 1% most anomalous events.

Unlike in the Gaussian case, for the LHC Olympics dataset we do not know the
probability densities analytically and so we can only estimate the densities
numerically. A comparison of the selected anomalies in the background-only
case with a NF are presented in Fig. 5. The shaded regions in Fig. 5 indicate
the selected anomalies using a 1% criteria. Interestingly, the two selections
agree on only about 20% of events. This means that even though we have the
same events and the same input features, we have different anomaly selections
depending on the coordinates we use to represent the events.

Analogously to the previous section, we compare anomaly detection strategies
in Fig. 6. We employ the same neural network models and hyperparameters as the
ones used in the Gaussian example. Once again, the performance of the weakly-
supervised training is independent from the choice of coordinates, while all
other algorithms show differences in performance based on the initial choice
of coordinates. The AE and NF have a similar performance, reinforcing the
claim that the approaches are targeting similar regions of phase space.
However, the change in performance after the coordinate transformation is more
pronounced for the AE, which may have other contributions aside from the
indirect density estimation.

(a)

(b)

Figure 6: (a) Receiver Operating Characteristic (ROC) curves for the three
anomaly detection algorithms evaluated using the LHC Olympics dataset for
different choices of inputs. The black line denotes the expected ROC curve for
a random algorithm. The number in parentheses represents the area under the
curve. (b) Same as (a), but instead of the background efficiency, the
dependent variable is the Significance Improvement Characteristic (SIC)
defined as the signal efficiency divided by the square root of the background
efficiency.

##  V Conclusions and Outlook

In this paper, we have described the sensitivity of anomaly detection
approaches to coordinate transformations. We have connected BSM hypotheses
with ML strategies in order to make explicit what is being assumed and when
coordinate transformations are potentially important. While it is not new, we
have highlighted the coordinate sensitivity of unsupervised approaches
(targeting ‘rare’ events). There is no optimal set of coordinates _a priori_ ,
but for a given signal hypothesis, some set of coordinates will be optimal for
a particular unsupervised learning algorithm. This does not mean that we
should not use unsupervised algorithms – on the contrary, these approaches
provide valuable complementarity to other less-than-supervised methods.
However, we should be cautious about optimal claims, and it seems wise to
explore multiple coordinate systems when determining the sensitivity. While
weakly-supervised approaches are formally coordinate-independent, it could be
that in practice some set of coordinates enables more efficient learning.
These and other practical issues are critically important to explore as
anomaly detection proposals become physics results in the near future.

## Code Availability

The code for this paper can be found at
https://github.com/ViniciusMikuni/Rareisnotuniversal.

## Acknowledgments

We are grateful to the participants, speakers, and co-organizers of the
PhyStat-Anomaly workshop (https://indico.cern.ch/event/1138933/) for many
useful discussions before, at, and after the meeting. We additionally thank
the participants of Hammers and Nails 2022 for useful discussions, especially
Kyle Cranmer. We also thank Sascha Caron, Bob Cousins, and Louis Lyons for
feedback on the manuscript. RM, VM, BN, and MP are supported by the U.S.
Department of Energy (DOE), Office of Science under contract DE-
AC02-05CH11231. This research used resources of the National Energy Research
Scientific Computing Center, a DOE Office of Science User Facility supported
by the Office of Science of the U.S. Department of Energy under Contract No.
DE-AC02-05CH11231 using NERSC award HEP-ERCAP0021099. This material is based
upon work supported by the National Science Foundation Graduate Research
Fellowship Program under Grant No. DGE 2146752. Any opinions, findings, and
conclusions or recommendations expressed in this material are those of the
author(s) and do not necessarily reflect the views of the National Science
Foundation. The work of DS was supported by DOE grant DOE-SC0010008. GK
acknowledges support by the Deutsche Forschungsgemeinschaft (DFG, German
Research Foundation) under Germany’s Excellence Strategy – EXC 2121 “Quantum
Universe” – 390833306.

## References

  * D’Agnolo and Wulzer [2019] R. T. D’Agnolo and A. Wulzer, Phys. Rev. D99, 015014 (2019), arXiv:1806.02350 [hep-ph] .
  * Collins  _et al._ [2018] J. H. Collins, K. Howe, and B. Nachman, Phys. Rev. Lett. 121, 241803 (2018), arXiv:1805.02664 [hep-ph] .
  * Collins  _et al._ [2019] J. H. Collins, K. Howe, and B. Nachman, Phys. Rev. D99, 014038 (2019), arXiv:1902.02634 [hep-ph] .
  * D’Agnolo  _et al._ [2019] R. T. D’Agnolo, G. Grosso, M. Pierini, A. Wulzer, and M. Zanetti,  (2019), 10.1140/epjc/s10052-021-08853-y, arXiv:1912.12155 [hep-ph] .
  * Farina  _et al._ [2018] M. Farina, Y. Nakai, and D. Shih,  (2018), 10.1103/PhysRevD.101.075021, arXiv:1808.08992 [hep-ph] .
  * Heimel  _et al._ [2019] T. Heimel, G. Kasieczka, T. Plehn, and J. M. Thompson, SciPost Phys. 6, 030 (2019), arXiv:1808.08979 [hep-ph] .
  * Roy and Vijay [2019] T. S. Roy and A. H. Vijay, (2019), arXiv:1903.02032 [hep-ph] .
  * Cerri  _et al._ [2019] O. Cerri, T. Q. Nguyen, M. Pierini, M. Spiropulu, and J.-R. Vlimant, JHEP 05, 036 (2019), arXiv:1811.10276 [hep-ex] .
  * Blance  _et al._ [2019] A. Blance, M. Spannowsky, and P. Waite, JHEP 10, 047 (2019), arXiv:1905.10384 [hep-ph] .
  * Hajer  _et al._ [2018] J. Hajer, Y.-Y. Li, T. Liu, and H. Wang,  (2018), 10.1103/PhysRevD.101.076015, arXiv:1807.10261 [hep-ph] .
  * De Simone and Jacques [2019] A. De Simone and T. Jacques, Eur. Phys. J. C79, 289 (2019), arXiv:1807.06038 [hep-ph] .
  * Mullin  _et al._ [2019] A. Mullin, H. Pacey, M. Parker, M. White, and S. Williams,  (2019), 10.1007/JHEP02(2021)160, arXiv:1912.10625 [hep-ph] .
  * Alessandro Casa [2019] G. M. Alessandro Casa, (2019), arXiv:1809.02977 [hep-ex] .
  * Dillon  _et al._ [2019] B. M. Dillon, D. A. Faroughy, and J. F. Kamenik, Phys. Rev. D100, 056002 (2019), arXiv:1904.04200 [hep-ph] .
  * Andreassen  _et al._ [2020] A. Andreassen, B. Nachman, and D. Shih, Phys. Rev. D 101, 095004 (2020), arXiv:2001.05001 [hep-ph] .
  * Nachman and Shih [2020] B. Nachman and D. Shih, Phys. Rev. D 101, 075042 (2020), arXiv:2001.04990 [hep-ph] .
  * Aguilar-Saavedra  _et al._ [2017] J. A. Aguilar-Saavedra, J. H. Collins, and R. K. Mishra, JHEP 11, 163 (2017), arXiv:1709.01087 [hep-ph] .
  * Romão Crispim  _et al._ [2020] M. Romão Crispim, N. Castro, R. Pedro, and T. Vale, Phys. Rev. D 101, 035042 (2020), arXiv:1912.04220 [hep-ph] .
  * Romao  _et al._ [2020a] M. C. Romao, N. Castro, J. Milhano, R. Pedro, and T. Vale,  (2020a), 10.1140/epjc/s10052-021-08891-6, arXiv:2004.09360 [hep-ph] .
  * Knapp  _et al._ [2020] O. Knapp, G. Dissertori, O. Cerri, T. Q. Nguyen, J.-R. Vlimant, and M. Pierini,  (2020), 10.1140/epjp/s13360-021-01109-4, arXiv:2005.01598 [hep-ex] .
  * ATLAS Collaboration [2020] ATLAS Collaboration,  (2020), 10.1103/PhysRevLett.125.131801, arXiv:2005.02983 [hep-ex] .
  * Dillon  _et al._ [2020] B. M. Dillon, D. A. Faroughy, J. F. Kamenik, and M. Szewc,  (2020), 10.1007/JHEP10(2020)206, arXiv:2005.12319 [hep-ph] .
  * Romao  _et al._ [2020b] M. C. Romao, N. Castro, and R. Pedro,  (2020b), 10.1140/epjc/s10052-020-08807-w, arXiv:2006.05432 [hep-ph] .
  * Amram and Suarez [2020] O. Amram and C. M. Suarez,  (2020), 10.1007/JHEP01(2021)153, arXiv:2002.12376 [hep-ph] .
  * Cheng  _et al._ [2020] T. Cheng, J.-F. Arguin, J. Leissner-Martin, J. Pilette, and T. Golling, (2020), arXiv:2007.01850 [hep-ph] .
  * Khosa and Sanz [2020] C. K. Khosa and V. Sanz, (2020), arXiv:2007.14462 [cs.LG] .
  * Thaprasop  _et al._ [2020] P. Thaprasop, K. Zhou, J. Steinheimer, and C. Herold, (2020), arXiv:2007.15830 [hep-ex] .
  * Alexander  _et al._ [2020] S. Alexander, S. Gleyzer, H. Parul, P. Reddy, M. W. Toomey, E. Usai, and R. Von Klar, (2020), arXiv:2008.12731 [astro-ph.CO] .
  * Aguilar-Saavedra  _et al._ [2020] J. A. Aguilar-Saavedra, F. R. Joaquim, and J. F. Seabra,  (2020), 10.1007/JHEP03(2021)012, arXiv:2008.12792 [hep-ph] .
  * Benkendorfer  _et al._ [2020] K. Benkendorfer, L. L. Pottier, and B. Nachman, (2020), arXiv:2009.02205 [hep-ph] .
  * Adrian Alan Pol and Victor Berger and Gianluca Cerminara and Cecile Germain and Maurizio Pierini [2020] Adrian Alan Pol and Victor Berger and Gianluca Cerminara and Cecile Germain and Maurizio Pierini, (2020), arXiv:2010.05531 [cs.LG] .
  * Mikuni and Canelli [2020] V. Mikuni and F. Canelli, (2020), arXiv:2010.07106 [physics.data-an] .
  * van Beekveld  _et al._ [2020] M. van Beekveld, S. Caron, L. Hendriks, P. Jackson, A. Leinweber, S. Otten, R. Patrick, R. Ruiz de Austri, M. Santoni, and M. White, (2020), arXiv:2010.07940 [hep-ph] .
  * Park  _et al._ [2020] S. E. Park, D. Rankin, S.-M. Udrescu, M. Yunus, and P. Harris, (2020), arXiv:2011.03550 [hep-ph] .
  * Faroughy [2020] D. A. Faroughy, (2020), arXiv:2012.08579 [hep-ph] .
  * Stein  _et al._ [2020] G. Stein, U. Seljak, and B. Dai, (2020), arXiv:2012.11638 [cs.LG] .
  * Kasieczka  _et al._ [2021a] G. Kasieczka _et al._ , (2021a), arXiv:2101.08320 [hep-ph] .
  * Chakravarti  _et al._ [2021] P. Chakravarti, M. Kuusela, J. Lei, and L. Wasserman, (2021), arXiv:2102.07679 [stat.AP] .
  * Batson  _et al._ [2021] J. Batson, C. G. Haaf, Y. Kahn, and D. A. Roberts, (2021), arXiv:2102.08380 [hep-ph] .
  * Blance and Spannowsky [2021] A. Blance and M. Spannowsky, (2021), arXiv:2103.03897 [hep-ph] .
  * Bortolato  _et al._ [2021] B. Bortolato, B. M. Dillon, J. F. Kamenik, and A. Smolkovič, (2021), arXiv:2103.06595 [hep-ph] .
  * Collins  _et al._ [2021] J. H. Collins, P. Martín-Ramiro, B. Nachman, and D. Shih, (2021), arXiv:2104.02092 [hep-ph] .
  * Dillon  _et al._ [2021] B. M. Dillon, T. Plehn, C. Sauer, and P. Sorrenson, (2021), arXiv:2104.08291 [hep-ph] .
  * Finke  _et al._ [2021] T. Finke, M. Krämer, A. Morandini, A. Mück, and I. Oleksiyuk, (2021), arXiv:2104.09051 [physics.data-an] .
  * Shih  _et al._ [2021] D. Shih, M. R. Buckley, L. Necib, and J. Tamanas, (2021), arXiv:2104.12789 [astro-ph.GA] .
  * Atkinson  _et al._ [2021] O. Atkinson, A. Bhardwaj, C. Englert, V. S. Ngairangbam, and M. Spannowsky, (2021), arXiv:2105.07988 [hep-ph] .
  * Kahn  _et al._ [2021] A. Kahn, J. Gonski, I. Ochoa, D. Williams, and G. Brooijmans, (2021), arXiv:2105.09274 [hep-ph] .
  * Aarrestad  _et al._ [2021] T. Aarrestad _et al._ , (2021), arXiv:2105.14027 [hep-ph] .
  * Dorigo  _et al._ [2021] T. Dorigo, M. Fumanelli, C. Maccani, M. Mojsovska, G. C. Strong, and B. Scarpa, (2021), arXiv:2106.05747 [physics.data-an] .
  * Caron  _et al._ [2021] S. Caron, L. Hendriks, and R. Verheyen, (2021), arXiv:2106.10164 [hep-ph] .
  * Govorkova  _et al._ [2021a] E. Govorkova, E. Puljak, T. Aarrestad, M. Pierini, K. A. Woźniak, and J. Ngadiuba, (2021a), arXiv:2107.02157 [physics.data-an] .
  * Kasieczka  _et al._ [2021b] G. Kasieczka, B. Nachman, and D. Shih (2021) arXiv:2107.02821 [stat.ML] .
  * Volkovich  _et al._ [2021] S. Volkovich, F. D. V. Halevy, and S. Bressler, (2021), arXiv:2107.11573 [hep-ex] .
  * Govorkova  _et al._ [2021b] E. Govorkova _et al._ , (2021b), arXiv:2108.03986 [physics.ins-det] .
  * Hallin  _et al._ [2021] A. Hallin, J. Isaacson, G. Kasieczka, C. Krause, B. Nachman, T. Quadfasel, M. Schlaffer, D. Shih, and M. Sommerhalder, (2021), arXiv:2109.00546 [hep-ph] .
  * Ostdiek [2021] B. Ostdiek, (2021), arXiv:2109.01695 [hep-ph] .
  * Fraser  _et al._ [2021] K. Fraser, S. Homiller, R. K. Mishra, B. Ostdiek, and M. D. Schwartz, (2021), arXiv:2110.06948 [cs.LG] .
  * Jawahar  _et al._ [2021] P. Jawahar, T. Aarrestad, M. Pierini, K. A. Wozniak, J. Ngadiuba, J. Duarte, and S. Tsan, (2021), arXiv:2110.08508 [hep-ph] .
  * Herrero-Garcia  _et al._ [2021] J. Herrero-Garcia, R. Patrick, and A. Scaffidi, (2021), arXiv:2110.12248 [hep-ph] .
  * Aguilar-Saavedra [2021] J. A. Aguilar-Saavedra, (2021), arXiv:2111.02647 [hep-ph] .
  * Tombs and Lester [2021] R. Tombs and C. G. Lester, (2021), arXiv:2111.05442 [hep-ph] .
  * Lester and Tombs [2021] C. G. Lester and R. Tombs, (2021), arXiv:2111.00616 [hep-ph] .
  * Mikuni  _et al._ [2021] V. Mikuni, B. Nachman, and D. Shih, (2021), arXiv:2111.06417 [cs.LG] .
  * Chekanov and Hopkins [2021] S. V. Chekanov and W. Hopkins, (2021), arXiv:2111.12119 [hep-ph] .
  * d’Agnolo  _et al._ [2021] R. T. d’Agnolo, G. Grosso, M. Pierini, A. Wulzer, and M. Zanetti, (2021), arXiv:2111.13633 [hep-ph] .
  * Canelli  _et al._ [2021] F. Canelli, A. de Cosa, L. L. Pottier, J. Niedziela, K. Pedro, and M. Pierini, (2021), arXiv:2112.02864 [hep-ph] .
  * Ngairangbam  _et al._ [2021] V. S. Ngairangbam, M. Spannowsky, and M. Takeuchi, (2021), arXiv:2112.04958 [hep-ph] .
  * Bradshaw  _et al._ [2022] L. Bradshaw, S. Chang, and B. Ostdiek, (2022), arXiv:2203.01343 [hep-ph] .
  * Aguilar-Saavedra [2022] J. A. Aguilar-Saavedra, (2022), arXiv:2201.11143 [hep-ph] .
  * Alvi  _et al._ [2022] S. Alvi, C. Bauer, and B. Nachman, (2022), arXiv:2206.08391 [hep-ph] .
  * Dillon  _et al._ [2022a] B. M. Dillon, R. Mastandrea, and B. Nachman, (2022a), arXiv:2205.10380 [hep-ph] .
  * Birman  _et al._ [2022] M. Birman, B. Nachman, R. Sebbah, G. Sela, O. Turetz, and S. Bressler, Eur. Phys. J. C 82, 508 (2022), arXiv:2203.07529 [hep-ph] .
  * Raine  _et al._ [2022] J. A. Raine, S. Klein, D. Sengupta, and T. Golling, (2022), arXiv:2203.09470 [hep-ph] .
  * Letizia  _et al._ [2022] M. Letizia, G. Losapio, M. Rando, G. Grosso, A. Wulzer, M. Pierini, M. Zanetti, and L. Rosasco, (2022), arXiv:2204.02317 [hep-ph] .
  * Fanelli  _et al._ [2022] C. Fanelli, J. Giroux, and Z. Papandreou, (2022), arXiv:2204.08609 [cs.LG] .
  * Verheyen [2022] R. Verheyen, (2022), arXiv:2205.01697 [hep-ph] .
  * Caron  _et al._ [2022] S. Caron, R. R. de Austri, and Z. Zhang, (2022), arXiv:2207.07631 [hep-ph] .
  * Dillon  _et al._ [2022b] B. M. Dillon, L. Favaro, T. Plehn, P. Sorrenson, and M. Krämer, (2022b), arXiv:2206.14225 [hep-ph] .
  * Buss  _et al._ [2022] T. Buss, B. M. Dillon, T. Finke, M. Krämer, A. Morandini, A. Mück, I. Oleksiyuk, and T. Plehn, (2022), arXiv:2202.00686 [hep-ph] .
  * Karagiorgi  _et al._ [2021] G. Karagiorgi, G. Kasieczka, S. Kravitz, B. Nachman, and D. Shih, (2021), arXiv:2112.03769 [hep-ph] .
  * Le Lan and Dinh [2021] C. Le Lan and L. Dinh, Entropy 23 (2021), 10.3390/e23121690.
  * Kingma and Welling [2014] D. P. Kingma and M. Welling, (2014), arXiv:1312.6114 [stat.ML] .
  * Kingma and Welling [2019] D. P. Kingma and M. Welling, Foundations and Trends in Machine Learning 12, 307 (2019).
  * Yoon  _et al._ [2021] S. Yoon, Y.-K. Noh, and F. C. Park, “Autoencoding under normalization constraints,”  (2021).
  * Goodfellow  _et al._ [2014] I. J. Goodfellow _et al._ , Conference on Neural Information Processing Systems 2, 2672 (2014).
  * Creswell  _et al._ [2018] A. Creswell, T. White, V. Dumoulin, K. Arulkumaran, B. Sengupta, and A. A. Bharath, IEEE Signal Processing Magazine 35, 53 (2018).
  * Rezende and Mohamed [2015] D. J. Rezende and S. Mohamed, International Conference on Machine Learning 37, 1530 (2015).
  * Kobyzev  _et al._ [2020] I. Kobyzev, S. Prince, and M. Brubaker, IEEE Transactions on Pattern Analysis and Machine Intelligence , 1 (2020).
  * Butter  _et al._ [2022] A. Butter, S. Diefenbacher, G. Kasieczka, B. Nachman, T. Plehn, D. Shih, and R. Winterhalder, (2022), arXiv:2202.09375 [hep-ph] .
  * Krzyzanska and Nachman [2022] K. Krzyzanska and B. Nachman, (2022), arXiv:2203.09601 [hep-ph] .
  * Hastie  _et al._ [2001] T. Hastie, R. Tibshirani, and J. Friedman,  _The Elements of Statistical Learning_ , Springer Series in Statistics (Springer New York Inc., New York, NY, USA, 2001).
  * Sugiyama  _et al._ [2012] M. Sugiyama, T. Suzuki, and T. Kanamori,  _Density Ratio Estimation in Machine Learning_ (Cambridge University Press, 2012).
  * Metodiev  _et al._ [2017] E. M. Metodiev, B. Nachman, and J. Thaler, JHEP 10, 174 (2017), arXiv:1708.02949 [hep-ph] .
  * Grathwohl  _et al._ [2018] W. Grathwohl, R. T. Chen, J. Bettencourt, I. Sutskever, and D. Duvenaud, arXiv preprint arXiv:1810.01367 (2018).
  * Abadi  _et al._ [2015] M. Abadi, A. Agarwal, P. Barham, E. Brevdo, Z. Chen, C. Citro, G. S. Corrado, A. Davis, J. Dean, M. Devin, S. Ghemawat, I. Goodfellow, A. Harp, G. Irving, M. Isard, Y. Jia, R. Jozefowicz, L. Kaiser, M. Kudlur, J. Levenberg, D. Mané, R. Monga, S. Moore, D. Murray, C. Olah, M. Schuster, J. Shlens, B. Steiner, I. Sutskever, K. Talwar, P. Tucker, V. Vanhoucke, V. Vasudevan, F. Viégas, O. Vinyals, P. Warden, M. Wattenberg, M. Wicke, Y. Yu, and X. Zheng, “TensorFlow: Large-scale machine learning on heterogeneous systems,”  (2015), software available from tensorflow.org.
  * Kingma and Ba [2015] D. P. Kingma and J. Ba,  _3rd International Conference on Learning Representations, ICLR 2015_ , (2015), arXiv:1412.6980 [cs.LG] .
  * Sjöstrand  _et al._ [2008] T. Sjöstrand, S. Mrenna, and P. Skands, Computer Physics Communications 178, 852–867 (2008).
  * de Favereau  _et al._ [2014] J. de Favereau, C. Delaere, P. Demin, A. Giammanco, V. Lemaître, A. Mertens, and M. Selvaggi, Journal of High Energy Physics 2014 (2014), 10.1007/jhep02(2014)057.
  * Mertens [2015] A. Mertens, Journal of Physics: Conference Series 608, 012045 (2015).
  * Selvaggi [2014] M. Selvaggi, Journal of Physics: Conference Series 523, 012033 (2014).
  * Cacciari  _et al._ [2012] M. Cacciari, G. P. Salam, and G. Soyez, The European Physical Journal C 72 (2012), 10.1140/epjc/s10052-012-1896-2.
  * Cacciari  _et al._ [2008] M. Cacciari, G. P. Salam, and G. Soyez, Journal of High Energy Physics 2008, 063 (2008).
  * Thaler and Van Tilburg [2012] J. Thaler and K. Van Tilburg, Journal of High Energy Physics 2012 (2012), 10.1007/jhep02(2012)093.
  * Thaler and Van Tilburg [2011] J. Thaler and K. Van Tilburg, Journal of High Energy Physics 2011 (2011), 10.1007/jhep03(2011)015.