Relational Symbolic Execution in WebAssembly1471675/...DEGREE PROJECT IN COMPUTER SCIENCE AND...

IN DEGREE PROJECT COMPUTER SCIENCE AND ENGINEERING,SECOND CYCLE, 30 CREDITS

, STOCKHOLM SWEDEN 2020

Relational Symbolic Execution in WebAssembly

JOHAN SJÖLÉN

KTH ROYAL INSTITUTE OF TECHNOLOGYSCHOOL OF ELECTRICAL ENGINEERING AND COMPUTER SCIENCE

Relational SymbolicExecution in WebAssembly

JOHAN SJÖLÉN

Master in Computer ScienceDate: 2020-08-29Supervisor: Musard BalliuExaminer: Roberto GuancialeSchool of Electrical Engineering and Computer ScienceSwedish title: Relationssymbolisk körning av WebAssembly

iii

AbstractWebAssembly is a new low-level language used as a compilation target whichruns in web browsers. As more code is run on the client side of a web appli-cation the issue of security of that code become more important.

Our work is based in the approach of using formal verification in order toprove that for a program one or more security properties hold. In this thesis wehave explored the usage of relational symbolic execution in order to performformal verification of security properties for WebAssembly programs.

We described a formal semantics of relational symbolic execution for We-bAssembly, implemented it in the Redex framework, extended the implemen-tation for verification of constant-time security, and used the implementationto formally verify multiple sample programs including Salsa20.

Our work shows that relational verification of standard security propertiessuch as non-interference and constant-time security by using relational sym-bolic execution for WebAssembly is a viable approach.

iv

SammanfattningWebAssembly är ett nytt lågnivåspråk vilket fungerar som kompileringsmåloch körs i webbläsare. Allt eftersom att mer programkod körs på klientsidanav webbprogram har säkerheten av dessa program blivit viktigare.

Vårt arbete nyttjar formella verifikationsmetoder för att bevisa att ett pro-gram uppfyller en eller flera säkerhetsegenskaper. Mer specifikt har vi i dettaexamensarbete utforskat användandet av relationssymbolisk exekvering i syf-te att utföra formell verifiering av säkerhetsegenskaper för WebAssemblypro-gram.

Vi har beskrivit en formell semantik för relationssymbolisk exekvering förWebAssembly, implementerat det i Redexramverket, utökat implementationenför verifiering av konstanttidssäkerhet samt använt implementationen för attformellt verifiera flera urval av program, inkluderande Salsa20.

Vårt arbete visar att relationell verifiering av standardsäkerhetsegenska-per såsom icke-interferens samt konstanttidssäkerhet är genomförbart via re-lationssymbolisk exekvering för WebAssembly.

v

AcknowledgementI would like to thank my supervisor Musard Balliu for the time and effort heinvested into discussing theory with me and advising me on the thesis report.

Contents

1 Introduction 11.1 Problem and Motivation . . . . . . . . . . . . . . . . . . . . 31.2 Related works . . . . . . . . . . . . . . . . . . . . . . . . . . 4

1.2.1 Self-compositon approach . . . . . . . . . . . . . . . 41.2.2 Type system approach . . . . . . . . . . . . . . . . . 41.2.3 Logics approach . . . . . . . . . . . . . . . . . . . . 51.2.4 Relational symbolic execution approach . . . . . . . . 6

1.3 Research Questions . . . . . . . . . . . . . . . . . . . . . . . 71.4 Ethics and sustainability . . . . . . . . . . . . . . . . . . . . 81.5 Contributions and outline . . . . . . . . . . . . . . . . . . . . 8

2 Preliminaries 92.1 Theory - Logic and semantics . . . . . . . . . . . . . . . . . 9

2.1.1 While language . . . . . . . . . . . . . . . . . . . . . 92.1.2 Hoare logic . . . . . . . . . . . . . . . . . . . . . . . 122.1.3 Relational properties . . . . . . . . . . . . . . . . . . 132.1.4 Relational execution . . . . . . . . . . . . . . . . . . 132.1.5 Symbolic execution . . . . . . . . . . . . . . . . . . . 16

2.2 WebAssembly . . . . . . . . . . . . . . . . . . . . . . . . . . 192.2.1 Type safety . . . . . . . . . . . . . . . . . . . . . . . 192.2.2 Control flow . . . . . . . . . . . . . . . . . . . . . . 20

3 Relational Symbolic Execution for WebAssembly 223.1 A useful fragment of WebAssembly . . . . . . . . . . . . . . 22

3.1.1 Semantics . . . . . . . . . . . . . . . . . . . . . . . . 243.2 Symbolic WebAssembly . . . . . . . . . . . . . . . . . . . . 26

3.2.1 Abstracting the heap . . . . . . . . . . . . . . . . . . 273.2.2 Symbolic semantics . . . . . . . . . . . . . . . . . . 293.2.3 Discharging to SMT solver . . . . . . . . . . . . . . . 31

vi

CONTENTS vii

3.2.4 Controlling state explosion . . . . . . . . . . . . . . . 323.3 Relational symbolic WebAssembly . . . . . . . . . . . . . . . 32

3.3.1 Semantics . . . . . . . . . . . . . . . . . . . . . . . . 333.3.2 Discharge to SMT solver re-visited . . . . . . . . . . . 343.3.3 Stepping and collecting configurations . . . . . . . . . 35

4 Results 364.1 Implementation and runtime environment . . . . . . . . . . . 364.2 Case studies . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

4.2.1 Program equivalence . . . . . . . . . . . . . . . . . . 374.2.2 Non-interference . . . . . . . . . . . . . . . . . . . . 394.2.3 Statistics . . . . . . . . . . . . . . . . . . . . . . . . 444.2.4 Constant-time WASM . . . . . . . . . . . . . . . . . 44

5 Discussion 495.1 Results and their limitations . . . . . . . . . . . . . . . . . . 495.2 Future work . . . . . . . . . . . . . . . . . . . . . . . . . . . 50

5.2.1 Reimplementation for performance . . . . . . . . . . 505.2.2 Addition of features . . . . . . . . . . . . . . . . . . . 50

6 Conclusions 52

Bibliography 53

A Full WebAssembly grammar 58

B Case studies generated counter examples 60

C Leakage model 65

D Salsa20 WebAssembly translation 67

E Leaked observations 79

Chapter 1

Introduction

Today it is not uncommon to do your shopping, banking, and private commu-nication over the internet. Since many of these tasks involve some level ofsecrecy the security of the applications where these tasks are performed is im-portant. As such, much effort has gone into ensuring the security of systems byusing technologies such as HTTPS in order to ensure that what the client sendsto the server is kept a secret. Websites have grown over the past 25 years fromdelivery of static HTML to full-blown applications with HTML, CSS, andJavaScript ranging in the megabytes being delivered to each user. The currenttrend is for client side computation to be favored as opposed to server sidecomputation, and as such the limitations of JavaScript performance wise hasbecome more noticeable and the need for a performant alternative has beenestablished. Development for such an alternative started in the early 2010swith efforts such as asm.js [1] which defined a subset of JavaScript that couldbe compiled into efficient native code by webbrowsers’ just-in-time compilers.Emscripten, a C/C++ to asm.js compiler [2], showed that such a runtime couldbe useful through porting large programs and running them in theweb browser.In 2015 WebAssembly was introduced, superseding asm.js. WebAssembly isa concerted effort between W3C, Mozilla, Microsoft, Google, and Apple tointroduce a low-level language with near native execution speed while beingsafer than traditional low-level languages. With WebAssembly boasting fea-tures such as structured control flow, formally defined stack machine seman-tics, and a static type system we believe that this is a language which is up tothe task of providing a more secure web. Others have already published re-search concerning static analysis and formal methods which strengthens thisbelief. Some of these is the type system CT-Wasm by Watt et al. [3] andprogram logics such as the one by Watt et al [4] .

1

2 CHAPTER 1. INTRODUCTION

In this thesis we will contribute further to this line of work as we present atool which can formally verify that several desirable security properties holdsfor arbitrary programs written in a practical fragment of the full WebAssemblyspecification.

CHAPTER 1. INTRODUCTION 3

1.1 Problem and MotivationOften formal verification is concerned with proving a functional correctnessproperty regarding execution of one program, for example that given an appro-priate input it will produce appropriate an output. However, many interestingproperties are naturally expressed by relating a program with two (or more)inputs or two (or more) programs with one input in some manner.

Let us consider a simple example and then move on to some propertieswhich are important to real world software. We will consider an example con-sisting of voting in a general election. We would like it to hold that the resultof a vote counting algorithm (P ), taking a sequence of votes as input, talliesthose votes identically regardless of the ordering of those votes. This is read-ily expressible by a relational property and would be stated by saying “Forall possible pairs of sequences of votes s1, s2, it holds that P (s1) = P (s2) ifs2 = σ(s1)” (where σ(x) means “a permutation of x”).

As it turns out many desired security and safety properties may be ex-pressed as relational properties of exactly two programs and one input or oneprogram and two inputs. Two examples of such properties are program equiv-alence and non-interference. Program equivalence expresses that two pro-grams produces the same output when given the same input. As compilersare programs which given a program as input produces another program withequivalent semantics this is an important property for them to hold. Non-interference expresses that given a set of secret variables and a set of publicvariables the value of the secret variables doesn’t interfere with the valuesof the public variables. A form of non-interference is constant-time security,which we have seen is quite important with attacks such as Spectre and Melt-down being widely publicized [5]. Constant-time security, in essence, meansto not branch on or access memory by values which are secret.

A traditional tool for allowing developers to prove properties regarding aprogram’s behaviour is Hoare logic named after C.A.R. Hoare who introducedthe notion in [6] and many computer systems can verify Hoare logic assertionsefficiently. However Hoare logic was designed with non-relational propertiesin mind, and so much work has gone into verifying relational properties usingsuch off the shelf systems andmany different approaches has been taken. Whatfollows is a summary of some of them, including the technique which we haveutilised in the work presented in this thesis.


1.2 Related worksSeveral methods for formal verification of relational properties of programshave been developed. We have considered four approaches: self-composition,the statically-typed, logics and symbolic execution approaches. Our researchis part of the symbolic execution approach. We now give a short overview ofeach of these approaches.

1.2.1 Self-compositon approachBy a method belonging to the self-composition approach we mean one whichoperates by manipulation of the abstract syntax trees of a program. That is,there is no interpretation of the meaning of a program that guides the method.The goal is instead to transform the program such that another off-the-shelfunary verification tool can be utilized to perform the relational verfication.

An example of such a method is self-composition and an early example foruse in relational verification was presented in [7] from 2011 by Barthe et al.Self-composition means to reduce an information flow policy of a program P

to a safety property about a single program P ;P ′ where P ′ is a renaming ofP .

This idea of utilizing a syntactic transformation of a program is also con-sidered in the concept of product programs. In Barthe et al. [8] we can againfind P and its renamed P ′, but this time each statement is intermingled in aspecific manner to produce a unary program.

Both of these tools utilize other off-the-shelf tools such as symbolic inter-preters to do the verification of the relational properties.

1.2.2 Type system approachType systems are tools which most programmers are familiar with. A type sys-tem attaches some semantic meaning of programs and conducts a check of theprogram which is equivalent to proof checking (as noted by Curry [9]) whileensuring that the check itself will terminate. Type system solutions inherentlyoverapproximate the semantics of the language.

One such solution for WebAssembly is a type system called CT-Wasm pre-sented by Watt et al [3]. CT-Wasm introduces secret and public types forWebAssembly values along with two new operations classify and declassify.These operations are only in effect during typechecking where classify makes


a public value secret and vice versa for declassify. They annotate whole heapsas secret or public 1.

This approach ensures that the type system can check that a program satis-fies what is called the constant-time security property. In short, the constant-time security property says that certain operations are leaky and reveals datato an attacker. This data should never be able to be observed by the attackerin order to infer something about some secret piece of data (such as a users’password). Typically what is considered a leaky operation is branching on asecret-dependent condition (revealing the condition data) or performing a heapaccess or store with a secret-dependent index (revealing where data was storedto or accessed in the heap).

The development of type systems for low-level assembly languages has along history, with an early example being TAL developed by Morrisett et al.in [10] which allows for expressing high-level language abstractions such asuser-defined records and closures for low-level RISC-like assembly languages.

Note that the type system based approaches are limited in that they canonly check a few specific properties which they were designed for, and thattheir semantic meaning may be very limited. Both of these are issues whichthe next method does not have.

1.2.3 Logics approachDefining a logic means to define a formal system with a set of logical ruleswith which to formally verify programs. We have identified two works whichare of particular relevance to our works. These are work by Watt et al. in [4],which defines a first-order logic for encapsulated WebAssembly, and seminalwork by Benton in [11], which defines a relational logic, allowing for theverification of relational properties.

Both of these are based in traditional Hoare logic, as first described byHoare in [6]. That is, they are based in describing a program along with a con-tract consisting of a pre- and post-condition as a hoare triple. A hoare tripleis of the form PCQ where P is the post-condition, C is the program,and Q is the post-condition. These contracts utilise an assertion language al-lowing for some specific expressivity. For example the assertion language inWatt et al.’s work include separation logic to describe the state of the heap. Fi-nally these triples may be automatically verified by using the set of structuralrules which define the logic. Typically logics are only concerned with partialcorrectness, that is termination needs to be proven separately.

1WebAssembly supports multiple heaps through its module system


1.2.4 Relational symbolic execution approachRelational symbolic execution discards the idea of syntactic transformation ofsome program and instead replaces it with an operational viewwhere relationalcommands and symbolic values are added to the language. For example valuesmay be unary (v) or paired ((vl, vr)) and are seen as purely symbolic. Theremay also exist a pair(l, r) command which is executed in a relational manner.This may allow for more efficient execution, since only a small part of the ex-ecution is required to be relational, as opposed to the purely syntactic productprograms. Proving a relational property may be done by discharging condi-tions to a SMT solver. A SMT solver is essentially a tool that given some logi-cal constraints returns if they are satisfiable or not. As opposed to for exampleCT-Wasm any relational property which is expressible to a SMT solver maybe verified. A relational symbolic interpreter might not terminate, this mayoccur because the program which it is interpreting is itself non-terminating.It may also have issues recognizing that a while-loop’s test condition is false(since such a test condition might depend on a symbolic value) and thereforemay not terminate. This is typically solved by requiring loop invariants to beprovided by the programmer or by setting a bound on the number of itera-tions per loop. A lot of work have been developed for this approach, startingwith the seminal work of Benton mentioned in the logics approach which notonly shows a relational hoare logic but which also shows a type system whichcaptures a form of secure information flow. Other works include but are notlimited to ENCoVer developed by Balliu et al. [12] which allows for modelchecking of non-interference like security policies utilizing epistemic logic,and the work by Farina et al. [13] which defines symbolic relational executionfor an imperative language.

This thesis explores the idea of relational symbolic execution for verifyingrelational properties of WebAssembly programs.


1.3 Research QuestionsWith the goal in mind being to explore the feasibility of verifying relationalproperties in WebAssembly we will now articulate two research questions andone goal which set out a proper scope for this work.

Can relational symbolic execution be formalized to a fragment of WebAssembly?

We will answer this question by presenting a fragment of WebAssemblyand formalizing both symbolic and relational symbolic execution for this frag-ment.

If such a formalization is possible we will implement a relational symbolicinterpreter and evaluate relational symbolic execution for a substantial

fragment of WebAssembly.

In order to do this we will extend the fragment previously presented and im-plement the interpreter in a programming language. We will then constructseveral case studies where multiple desirable relational properties are verifiedfor example programs.

How does our relational symbolic interpreter compare to existing methods for WebAssembly?

We hypothesize that other, static, solutions such as specialized type sys-tems are insufficient in verifying more complex properties because of theirlack of dynamic runtime information. In order to test this we will compareour solution to that of CT-wasm[3] which is a type-based solution for verifi-cation of constant time safety properties.


1.4 Ethics and sustainabilityThe work in this thesis only required the usage of consumer electronics. Wedid not collect data from any human test subjects, therefore there is no ethicalissue with the handling of their data. Our tool allows the formal verification ofabsence of certain vulnerabilities, this means that it may be used as a tool todiscover security flaws. Clearly such a tool is useful to both attackers as wellas those developing secure software. The content of this report is focused onsoftware security, as such no sustainability issues have been identified.

1.5 Contributions and outlineThe remainder of this report is separated into multiple chapters. First comesthe preliminaries, which will introduce key concepts and terminology. If thereader is inexperienced with the problem area then reading this chapter indepth is recommended, otherwise a quick skim ought to be sufficient.

The contributions are developed in chapters 3 and 4. The former presentsthe formal semantics of a relational symbolic interpreter for a small fragmentof WebAssembly. The latter then utilizes the interpreter on a series of simplecase studies, specifically case studies verifying program equivalence and non-interference properties. Finally we develop a solution for verifying a constant-time property and utilize this solution in order to verify an implementation ofthe Salsa20 cipher (as described by Bernstein [14]).

To summarize, our contributions are the following:

• A relational symbolic interpreter for a practical fragment ofWebAssem-bly (source code available at: https://github.com/jsjolen/relsym-wasm)

• A formal semantics presented of the interpreter (chapter 3)

• A formalization of constant-time properties using that interpreter (chap-ter 4)

• Some case studies illustrating the practicality of our approach (chapter4)

https://github.com/jsjolen/relsym-wasm


Chapter 2

Preliminaries

This chapter contains introductory material for the concepts which we buildupon in chapter 3.

We typeset inline comments using the following style.

2.1 Theory - Logic and semanticsIn this section we will explore the central theoretical concepts which our workis based upon. We will start by presenting a toy imperative language calledWhile. We will use this language in order to put the rest of the concepts intocontext. After that we will describe Hoare logic, relational properties, rela-tional execution, and symbolic execution.

2.1.1 While languageThe While language is composed of commands (c ∈ 〈C〉), expressions overthe integers (e ∈ 〈Expr〉), values (z ∈ Z), and variables (v ∈ 〈Var〉). Weexpress booleans by letting 1 being true and 0 being false.

In Figure 2.1 the definition of the grammar of commands is presented inBackus-Naur form.

We define a store for While to be a mapping from variables to values,that is a store is s ∈ 〈Var〉 → Z. Finally we define a configuration for theWhile language to be a pair 〈s, c〉. A configuration encodes the entire staterepresenting a program and its execution, so for While we include both someprogram c to be executed and some state s where assignments can be done. Afinal configuration is one where the program has finished executing, we encodesuch a configuration in While as 〈s, ε〉.

9

10 CHAPTER 2. PRELIMINARIES

〈C〉 ::= 〈C〉;〈C〉 Composition| 〈Var〉 := 〈Expr〉 Assignment| if 〈Expr〉 then 〈C〉 else 〈C〉 endif Conditional| while 〈Expr〉〈C〉endwhile Loop| skip Do nothing| ε End of program

〈Expr〉 ::= Z Values| 〈Expr〉 + 〈Expr〉| 〈Expr〉 - 〈Expr〉| 〈Expr〉 = 〈Expr〉 Equality comparison

Figure 2.1: Grammar of the While-language.

An experienced programmer may infer the meaning of a While program,1, nonetheless we will formalize part of While’s semantics by presenting op-erational semantics (also called small step semantics) in the style of Plotkin[15] and evaluation context reduction rules in the style of Felleisen-Hieb [16].In the rest of the thesis we will only use Felleisen-Hieb style reduction ruleshowever Plotkin’s style with its inspiration from logic is more familiar to theaverage computer scientist and is therefore useful as an introduction.

Defining semantics

Semanticsmay be defined using reduction rules. These are similar to inferencerules as used in conventional logic. Such rules utilize structural recursion.

We will now describe two rules which define part of the semantics of theWhile language (see Figure 2.2). The first rule is the [If-true] rule. To readthis rule, first start by the (1) and read everything before the ⇒. This is thestate that the configuration is currently in. Then read (2), this is the state thatthe configuration will reduce to if this rule applies. Finally read everythingabove the line in the middle (by (3)). This is the set of conditions which musthold if the rule can be applied. The ⇑ is similar in function to the⇒ but onlyapplies to expressions.

In plain English this can be read as the following:1The meaning of a program if you will

CHAPTER 2. PRELIMINARIES 11

(1)A configuration whose code is if e then cthn else cels endif reducesto (2) cthn if (3) e reduces to 1.

The second rule is for while loops. As an exercise, you may do the sametranslation into plain English as was done for the [If-true] rule.

[If-true](3)〈s, e〉 ⇑ 1

〈s, (1)if e then cthn else cels endif〉 ⇒ 〈s, (2)cthn〉

[While-loop]〈s, e〉 ⇑ 1

〈s,while e c endwhile〉 ⇒ 〈s, c;while e c endwhile〉

Figure 2.2: [If-true] and [While-loop] semantics in Plotkin-style.

Now we shall consider Felleisen-Hieb style reduction rules. Such reduc-tion rules depends on defining an evaluation context which specifies specificplaces where holes can occur which can then be plugged with a value. To doso we must first define an evaluation context as seen in Figure 2.3

The hole is [] and can be seen as a place where the next computationalstep can take place. Given a program 〈C〉 we can find some hole 〈E〉 andsubprogram 〈C〉’ such that 〈C〉 = 〈E〉[〈C〉′]. The term 〈E〉[〈C〉′] is read as“in the hole 〈E〉 the next computation step to be done will evaluate 〈C〉′”.Computations are done by replacing 〈C〉′ with some appropriate expressions.

The equivalent reduction rules whichwere previously presented in Plotkin-style along with the rest of the semantics is as in Figure 2.4.

Note that there is no need to evaluate the test condition explicitly, this isbecause the definition of the evaluation context specifies that the test-conditionmust be evaluated first. This style allows for succinct rules where the order ofevaluation becomes irrelevant to single rules, heavily simplifying the defini-tion of evaluation for larger languages.

〈E〉 ::= []| 〈E〉 ; 〈C〉 First evaluate left| 〈Var〉 := 〈E〉| if 〈E〉 then 〈C〉 else 〈C〉 Test-condition first

Figure 2.3: Evaluation context for While.


[If-true] 〈s, 〈E〉[if 1 then cthn else cels]〉 → 〈s, 〈E〉[cthn]〉

[While-loop] 〈s, 〈E〉[while e c]〉 → 〈s, 〈E〉[if e then c;while e c else skip]〉

[If-false] 〈s, 〈E〉[if 0 then cthn else cels]〉 → 〈s, 〈E〉[cels]〉

[Ass] 〈s, 〈E〉[v := z]〉 → 〈s[v 7→ z], 〈E〉[]〉

[Skip] 〈s, 〈E〉[skip]〉 → 〈s, 〈E〉[]〉

Figure 2.4: While expressed as Felleisen-Hieb style reduction relation

2.1.2 Hoare logicHoare logic, introduced by Tony Hoare in [6], is a formal verification systembased on Hoare triples. A Hoare triple, notated as P C Q where P andQ are assertions in some assertion language (a logic) and C is a command inour While-language. Such an assertion language is great for stating propertieson single programs, an example would be Figure 2.5 which states that theprogram computes the factorial of n. This Hoare triple can then be verifiedthrough some proof system.

1 x=x0 ∧ n =02 while (x >0)3 n := n*x4 x := x -15 endwhile6 n = x0!

Figure 2.5: Hoare triple and factorial program.

However such triples prove insufficient when attempting to express prop-erties that formalize how two programs relate to each other. This leads to aseparate definition of relational properties which we will define next.


Ry−independent = ((s1, s′1), (s2, s

′2))|s1(y) = s2(y)⇒ s′1(y) = s′2(y)

Figure 2.6: Relational property expressing y being independent.

2.1.3 Relational propertiesRelational properties relate two or more initial and final state pairs to eachother. We will focus on relational properties which talk about exactly 2 initialand final states.

Formally a relational property is defined in Definition 1, this definition istaken from Beckert and Ulbrich’s work [17].

Definition 1. Relational property. A relational property R is a set of statepairs, that is R ⊂ (S × S)(S × S). Two programs P1, P2 satisfy R iff∀s1, s′1, s2, s′2 ∈ S.s1

P1−→ s′1 ∧ s2P2−→ s′2 ⇒ ((s1, s

′1), (s2, s

′2)) ∈ R

One example of a relational property would be one which says that y is thesame in the final state regardless of the value of the other variables. Later onin this thesis a more general property will be presented based on this one. Theproperty may be expressed directly in the above notation as in Figure 2.6.

As we relate two initial states and two final states it becomes relevant tobe able to reduce two initial programs concurrently. We will now define arelational execution which allows for precisely that.

2.1.4 Relational executionWe allow for relational execution of the While-language by extending it inthree ways:

• We extend stores from being a mapping V ar → Z to being one V ar →(Z ∪ ⊥× Z ∪ ⊥) ∪ Z where ⊥ signifies that a value is missing.

• The grammar is extendedwith a new non-terminal 〈RC〉 ::= pair〈C〉〈C〉where rc ∈ 〈RC〉

• The configuration is changed from 〈s, c〉 to 〈s, rc〉

With these additions two concrete executions can now be executed in astep-wise fashion. This is not very useful in itself but when combined with


symbolic execution wewill have relational executions representing all possiblepairwise execution paths.

Stores and pair commands can be projected either to the left or the right,for example bpair cleft crightcleft ≡ cleft for the pair command and bx →(1, 2)cleft ≡ x → 1 for a store. Stores can also be merged, for examplemerge-store(x→ 1, x→ 2) ≡ x→ (1, 2).

All that is needed from a relational execution is to define how each differ-ent pairing of instruction from 〈C〉 ought to reduce. In essence, unless eitherthe left or right projection is a branching command (while or if in While) thenjust perform stepwise reduction, otherwise wait until the opposite projectionconfiguration either also reaches a branching command or is final. The re-ductions of projected configurations are done by another reduction relation, inthis case it is the concrete unary semantics we presented earlier. This reduc-tion relation is referred to as →, as opposed to the relational rel−→. We omitthe [Then/Else],[Else/Then], and [Else/Else] rules for brevity’s sake. Theserules are equivalent to the [Then/Then] rule, but with different branches takendepending on the values of the branching condition.


[If/e]〈s, 〈E〉[pair 〈E〉left[if zl then cthn else cels] cright]〉rel−→

〈s′〈E〉[pair 〈E〉left[if zl then cthn else cels ]c′right]〉where cright 6≡ 〈E〉right[if zr then cthn−right else cels−right]

and 〈s, cright〉 → 〈s′, c′right〉

[e/If]〈s, 〈E〉[pair cleft 〈E〉right[if zr then cthn else cels]]〉rel−→

〈s′〈E〉[pair c′left 〈E〉right[if zr then cthn else cels]]〉where cleft 6≡ 〈E〉left[if zl then cthn−left else cels−left]

and 〈s, cleft〉 → 〈s′, c′left〉

[Then/Then]〈s, 〈E〉[pair 〈E〉left[if 1 then cthn−l else cels−l]

〈E〉right[if 1 then cthn−r else cels−r ]]〉rel−→ 〈s, 〈E〉[pair 〈E〉left[cthn−l]〈E〉right[cthn−r]]

[Pair-step]〈s, 〈E〉[pair cleft cright]〉rel−→ 〈merge-store(s′left, s

′right), 〈E〉[pair c′left c′right]〉

where cright 6≡ 〈E〉right[if z then cthn−right else cels−right]

where cleft 6≡ 〈E〉left[if z then cthn−left else cels−left]

where 〈s, cleft〉 → 〈s′left, c′left〉and 〈s, cright〉 → 〈s′right, c′right〉

Figure 2.7: Reduction rules for relational execution of While.

The relevance of this ordering becomes apparent when execution is ex-tended to a symbolic context. This is because depending on how the semanticsare defined an interpreter implementing them may yield different efficiency inexecution.

The example in Figure 2.8 illustrates how the store splits into two duringreduction and is an application of the [Pair-step] rule.


〈, x := 5 | y := 5〉 rel−→〈x→ (5,⊥), y → (⊥, 5), ε〉

Figure 2.8: Example assignment for relational execution.

2.1.5 Symbolic executionSymbolic execution first appeared in the 1970s, with early work presented byBoyer et al. [18] and by King [19]. There are many use cases for symbolicexecution, but our goal is to allow us to verify Hoare-style properties.

Several changes has to be made to the interpreter in order to make it sym-bolic. The first is that some set of operations will operate on a purely syntacticlevel. In the While-language this will occur for operations performed with ⇑.Consider the assignment in 2.9.

〈x→ x0, y := x+ 5〉 sym−−→〈x→ x0, y→ x0 + 5, ε〉

Figure 2.9: Example of symbolic addition.

In the initial store x is assigned to the symbolic variable x0 and the storeafter the reduction shows that y is assigned to the syntactic object x0 + 5.

The second change to the interpreter is the addition of a path condition,which we append to configuration. That is, configurations are now a triples, c, pc. A path condition is a set of logical assertions generated through ex-ecution of the program. Since the test condition of an if or while commandmay depend on a symbolic value the introduction of non-determinism becomesnecessary. We model non-determinism by defining several rules which maybe applicable at the same time.

For example we can define non-deterministic reduction rules for if as inFigure 2.10. Note that this also illustrates the usage of the path condition inorder to record what the asserted value of the symbolic variable is.


[If-true]〈s, 〈E〉[if e then cthn else cels], pc〉sym−−→ 〈s, cthn, pc ∧ e = 1〉

[If-false]〈s, 〈E〉[if e then cthn else cels], pc〉sym−−→ 〈s, cels, pc ∧ e = 0〉

Figure 2.10: Symbolic reduction rules for the if command.

Loops, branching and state explosion

There are a few limiting issues with regards to symbolic execution. We have al-readymentioned the source of one of these limiting issues, and that is the expo-nential state explosion which occurs because of the non-determinism presentwhen branching. There are no solutions to this, the most we can do is provethat a certain configuration is impossible because of some contradiction in thepath condition and therefore safely discard such a configuration.

Another issue is with regards to loops. Because of the introduction ofsymbolic values it is possible that a loop condition can never be proven to befalse, and therefore an interpreter cannot soundly exit from a loop. This canbe solved by introducing loop invariants, indeed that is what Farina et al. doesin [13]. Our work does not include loop invariants however, and so care mustbe taken when performing case studies to ensure that loops exit condition al-ways depend on concrete values (in essence, the lops must be iterate a constantnumber of times).

Discharging the path condition

Consider the program in Figure 2.11.

x := 5;if x = 5

then skipelse skip unreachable

Figure 2.11: Unreachable branch example.

Clearly the else branch will never be taken. Let us now do a pen-and-paperrun of our symbolic interpreter over this code.


〈, x := 5; if x = 5 then skip else skip, true〉 sym−−→

〈x→ 5, if x = 5 then skip else skip, true〉 sym−−→

〈x→ 5, skip, true ∧ x = 5〉, 〈x→ 5, skip, true ∧ ¬x = 5〉 sym−−→〈x→ 5, ε, true ∧ x = 5〉, 〈x→ 5, ε, true ∧ ¬x = 5〉

Figure 2.12: Unreachable branch execution.

Here the two final configurations differ only in their path condition. Thelatter configuration contains a contradiction, in that it says that x is both 5(from the store) and not 5 (from the path condition). If a configuration containscontradictions then there cannot exist a concrete assignment of the variablesin the store and in the path condition which satisfies the path condition.

To know if there is a satisfiable concrete assignment to a configuration wecan utilize SMT solvers. These solvers were first introduced by Davis et al.[20] in the 1960s and has seen major development over the decades with mod-ern ones such as Z3 being introduced in 2008 and in active development aslate as 2020 by Microsoft[21][22]. The specifics of how these solvers work,while interesting, is not relevant to the rest of the thesis. Instead think of theseas black boxes which, given some state, tells us if there is a satisfiable assign-ment (and an example of such an assignment) or that there is no satisfiableassignment (that is, it is unsatisfiable). Finding satisfiable assignments for apropositional logic formula is NP-complete (see Cook [23]), and as such assuch a SMT solver’s runtime for a problem may be quite large.

Strongest post-condition

Symbolic execution is a functioning formal verification approach because itcomputes what is called the strongest post-condition. That is, it computes aset of path conditions, PC, for a program C such that given a contract (P,Q)the following holds if and only if the property which is being proven is validfor P :

∀s ∈ Store.s |= P ⇒pc∧PC

pc⇒ Q

In terms of Hoare logic this means that for some Hoare contract, (P,Q), andfor all initial configurations for which P holds, 〈s, c〉 |= P ,.


2.2 WebAssemblyWebAssembly is a new low-level language with the high-level goals of beingefficient to decode on the fly and execute and is mainly targetting the currentweb platform [24]. It is a statically typed stack-machine architecture, includingsupport for heaps, global variables, constants and local variables for functioncalls. WebAssembly also supports modules and indirect function calls througha function table, however both of these features are not considered in our workand so will not be discussed in any detail.

The semantics of our WebAssembly fragment is based upon the work in[25] by Rossberg et al., therefore small digressions from the official specifica-tion may occur. A WebAssembly configuration is a triple 〈s, F, e∗〉 where sis the current store containing the heap and global variable vector , F is thecurrent frame which is the local variable vector of the current function call ande∗ is the stack of data and instructions to be executed.

The heap is a vector of octets and the global variables and frame are 0-indexed lookup tables with slots of any primitive WebAssembly type.

2.2.1 Type safetyWebAssembly is a statically typed programming language. Type systems area means of ensuring that certain properties hold for a program, typically withan end goal being that a well typed program does not crash. Traditionallytwo properties are ensured by a type system (as specified by Felleisen et al.in [26]), these properties are called progress and preservation. Progress saysthat a well-typed program will either reduce to another reducible expressionor it will be a value. Preservation says that a well-typed program will onlyreduce to other well-typed programs. Rossberg et al. defines these propertiesfor WebAssembly in [25].

The progress property says that a program will either reduce or it will bea value. In WebAssembly this means that the stack only consists of values,which are encoded as (t.const v) instructions. From this we get a def-inition for final configurations, which says that a final configuration in We-bAssembly is one where the stack only consists of values.


WebAssembly type annotations

Almost all instructions2 in WebAssembly are annotated with a type, for exam-ple the t.const instruction just seen is annotated with the type t, for examplei32.const 5. Type annotated instructions are either annotated with a sin-gle type (like t.const) or with an arrow type which describes the effect thatthe instruction has on the stack. One such instruction is the instruction forlooping, which is defined as follows:

loop (tn → tm) e∗ end

The arrow type (also formatted as tf ) says that there must be n poppablevalues on the stack ’on-top’ of the loop instruction andm instructions will bepushed on the stack by the loop instruction when finished. A consequenceof typing the stack in this manner is that a well-typed WebAssembly programalways has a valid stack, meaning that the progress and preservation propertiesfrom above are valid.

2.2.2 Control flowWebAssembly’s control flow is more structured compared to other low-levellanguages. WebAssembly takes an approach inspired by structured program-ming, instead of exposing an arbitrary dynamically computed goto as shownin [27] by Bohm et al. More specifically, WebAssembly supports a blockinstruction, an if-then-else instruction, a loop instruction along with(mutual) recursion through the call.

Each of these instructions are reduced into (label n e*) where nis its argument arity and e* is a continuation. The continuation is only usedby loop, where the continuation is the full loop-instruction again.

All constructs can be unwound using the (br i) construct, which un-winds to the ith label continuation, with 0 being the closest. That is, controlflow can only move from an inner label to an outer one using (br i).

Let us consider two examples in Figure 2.13 and Figure 2.14 showinghow control flow works in WebAssembly where the nop instruction showswhere the break jumps to. Note that breaking to a block is forwards jumping,while breaking to a loop is backwards jumping.

2Exclusions to the rule are instructions such as trap which is there only to signify for-bidden code paths.


1 ( block ([] → []) b2 ( block ([] → [])3 ( loop ([] → [])4 (br 2)))5 nop )6

Figure 2.13: Break 2 steps, jump forwards.

1 ( loop ([] → [])2 nop3 (br 0))4

Figure 2.14: Break 0 steps, jump backwards.

Chapter 3

Relational Symbolic Executionfor WebAssembly

With the preliminaries explained we can now go ahead and first describe ourimplementation of WebAssembly in greater detail (Section A useful fragmentof WebAssembly), then move on to symbolic WebAssembly (Section Sym-bolic WebAssembly), and finally develop relational symbolic WebAssembly(Section Relational symbolic WebAssembly).

3.1 A useful fragment of WebAssemblyIn order to make the work feasible we decided to reduce the WebAssemblyspecification presented by Rossberg et al. [25] to a useful core. The simplifi-cations listed in 3.1 were made.

22

CHAPTER 3. RELATIONAL SYMBOLIC EXECUTION FORWEBASSEMBLY 23

• Modules are removed

• The set of datatypes is reduced to 32-bit integers only (32-bit was chosensince the heap is at most 231 − 1 bytes large)

• Dynamic function calls are removed. In other words, it is statically de-ducible which function is being called. This is important when valuesare raised into the symbolic domain.

• Only a small set of operations are kept, to lower the burden of imple-mentation.

• Only 4-byte aligned stores and loads are allowed. In other wordsheap[x] is allowed iff x(mod4) ≡ 0.

Figure 3.1: WebAssembly simplifications.

Control flow, local frame variables, global variables and heap access iskept intact.

In this chapter we discuss an even smaller fragment of this language. Thisis sufficient to illustrate the contributions of our work. The grammar of thislanguage is presented in Figure 3.2.

24 CHAPTER 3. RELATIONAL SYMBOLIC EXECUTION FORWEBASSEMBLY

t ::= i32

tf ::= ([t ...] → [t ...])

e-no-v ::= (block tf e*) | (loop tf e*) | (if tf then e* else e*) | (br i)

| (i32.load oset) | (i32.store oset)

| op

| (label n e* e*)

v ::= (i32.const c)

e ::= e-no-v | v

mem ::= Vector<u8>

op ::= binop-i | relop-i

relop-i ::= i32.eq

binop-i ::= i32.add | i32.sub | i32.mul | i32.and | i32.or

e* ::= ϵ

| (e e*)

v* ::= ϵ

| (v v*)

c ::= integer

oset ::= integer

Cong ::= mem ; e*

FinalCong ::= mem ; v*

E ::= []

| (v E)

| ((label n e* E) e*)

Figure 3.2: Grammar of minimal WebAssembly

A configuration Config is defined as consisting of the pairmem; e∗ withmem being the current heap (a vector of octets), and e∗ being the current stack.E, the evaluation context, picks the left-most non-value instruction as the nextto be executed. It also describes how to reduce expression stacks containedwithin a label instruction. Label instructions is the generic control-flow in-struction which all others reduce into. The supported control flow instructionsare block, loop, and if, as defined by e-v. A final configuration, defined byFinalConfig, is one which consists solely of values.

3.1.1 SemanticsWewill present the semantics piecewise, excluding some administratory tasksdelegated to metafunctions.


mem ; E[((i32.const c0) (i32.const c1) op e*)] [Operation]

mem ; E[((i32.const c2) e*)]

where c2 = do-op⟦op, c0, c1⟧

mem ; E[((i32.const c) (i32.load oset) e*)] [Load]

mem ; E[((i32.const c1) e*)]

where c1 = load-i32⟦mem, c + oset⟧

mem0 ; E[((i32.const c0) (i32.const c1) (i32.store oset) e*)] [Store]

mem1 ; E[e*]

where mem1 = store-i32⟦mem0, c0 + oset, c1⟧

Figure 3.3: Heap and operation rules for core WebAssembly.

In the [Operation] rule the function do-op performs the computation of theoperation op with the operands c0,c1 and reduces by replacing c0,c1 with theresult of do-op, c2, on the stack. The function store-i32 produces a new heapwith the specified index changed, and the [Store] rule reduces into a configura-tion where this new heap is used. The [Load] rule reduces by loading an indexfrom the heap and replacing the index with the loaded element on the stack.Let us now consider the main control flow instructions for WebAssembly.

mem ; E[((i32.const 0) (if tf then e*thn else e*els) e*)] [If-false]

mem ; E[((block tf e*els) e*)]

mem ; E[((i32.const k) (if tf then e*thn else e*els) e*)] [If-true]

mem ; E[((block tf e*thn) e*)]

where k ≠ 0

mem ; E[(eloop e*1)] [Loop]

mem ; Eouter[(elbl e*1)]

where l = [tm ...], k = [tn ...], (Eouter Ev) = v-split⟦E, k⟧, elbl = (label l eloop Ev[e*0]), eloop = (loop ([tn ...] → [tm ...]) e*0)

mem ; E[((block ([tn ...] → [tm ...]) e*body) e*cont)] [Block]

mem ; Eouter[((label l ϵ Ev[e*body]) e*cont)]

where l = [tn ...], k = [tm ...], (Eouter Ev) = v-split⟦E, k⟧

Figure 3.4: Control flow rules for core WebAssembly.

As can be seen in Figure 3.4 [If-true] and [If-false] inspect the stack inorder to infer which rule ought to be applied. One complexity in these rules isthe usage of v-split in the [Block] and [Loop] rule. v-split splits an evaluationcontext into two. An outer one surrounding the inner context which has nestedvalues around a hole. This is used in order to extract values on the stack intosome other stack, as required by operations with a function type signature.

Now the way that forward and respectively backwards breaks are imple-


mented becomes clear. Block (see [Block]) and loop (see [Loop]) instructionsare both turned into label instructions, with loop and its body is saved as acontinuation in the label.

Finally let us consider the specific rules regarding the label instruction.

mem ; E[((label n e*cont v*) e*outer)] [Label-value]

mem ; E[(v* e*outer)]

mem ; E[((label n e*cont Einner[((br j) e*1)]) e*2)] [Label-br]

mem ; E[(Ev[e*cont] e*2)]

where j = label-depth⟦Einner⟧, (Eouter Ev) = v-split⟦Einner, n⟧

Figure 3.5: Label rules for core WebAssembly.

If a label is br:d to the [Label-br] rule is invoked and its continuation isplaced on the stack, this is how looping is achieved. The label-depth meta-function computes the number of labels within an evaluation context, allowingus to pattern match on the correct label to branch to.

Note that the evaluation context in the grammar defines how to reducewithin a label instruction.

3.2 Symbolic WebAssemblyTo write a symbolic interpreter for WebAssembly we first extend the grammarof the concrete WebAssembly. Values are raised into the symbolic domain byextending c such that c ∈ i32 ∪ S where S is the set of symbolic variables.In our grammar it is defined by the non-terminal sym-var which says that allsyntactic objects with a prefix of sym-var is considered as part of the symbolicvariables (for example sym-var-x is a symbolic variable, x is not). Along withthis the representation of the heap is changed to a sequence of store and selectexpressions. We will expand on this in the next subsection.

A path condition is defined as a sequence of logical assertions, which areimplicitly∧:ed together. Constraint expressions are arithmetic operations overZ∪S. An implication of replacingi32withZ is that there is a loss of precisionin the logical assertions. This loss of precision would be made apparent whenoverflow, underflow or shift operators occur.

The definition of Config is extended to include a path condition. Se-quences of Configs are defined by Config∗ along with another evaluationcontext EE which captures an evaluation order for sequences of configura-tions. This ordering is arbitrary, any evaluation order is sufficient as long as all


configurations will be reduced into their final state (if such a state exists). Se-quences of configurations are used in order to capture non-determinism whilekeeping all of the rules deterministic. We will come back to this concept laterwhen the semantics are introduced in Subsection 3.2.2 at which point the use-fulness will become clear.

sym-var ::= (variable-prefix sym-var)

c ::= .... | sym-var | constr-expr

constr-expr ::= ArithmeticExpr

constr ::= false

| (= constr-expr constr-expr) | (< constr-expr constr-expr) | (> constr-expr constr-expr)

| (select constr-expr constr-expr) | (store constr-expr constr-expr)

pc ::= ϵ | (constr pc)

meminst ::= (select c c) | (store c c)

mem ::= ϵ

| (meminst mem)

Cong ::= (mem ; e* ; pc)

Cong* ::= ϵ | (Cong Cong*)

EE ::= []

| ((mem ; v* ; pc) EE)

Figure 3.6: Extended grammar for symbolic WebAssembly.

Before the re-defined semantics for our symbolic interpreter is presentedwe will first expand on the choice of switching representation ofmem.

3.2.1 Abstracting the heapRepresentation of the heap must be changed. To see why, consider the codesnippet (const i32 sym-var) (store i32 0 0). No longer canthe interpreter know which sequence of bytes are referenced in the heap. Tosolve this issue we must abstract the heap.

We will abstract the heap by utilizing a lightly modified version of Mc-Carthy’s “Theory of Arrays” from his seminal paper [28]. McCarthy’s orig-inal theory consists of two functions, select and store, operating on avector, V , of non-specific size. A SMT solver may implement these functionsas a way of expressing the contents of vectors and access to the contents ofthat vector. They are presented alongside our updated versions along with theaxiomatization of the theory.

Two things are changed from McCarthy’s definition: The vector argumentis moved furthest to the right and is curried. The function select takes an


select_M : V × N→ Z

store_M : V × N× Z→ V

Figure 3.7: McCarthy’s definition of store and select.

select : N× S → (V → V )

store : N× Z→ (V → V )

Figure 3.8: Updated definition of store and select.

∀v ∈ V, i, j ∈ N, e ∈ Z.i = j ⇒ select_M(store_M(v, j, e), j) = e ∧i 6= j ⇒ select_M(store_M(v, j, e), j) = select_M(v, j)

Figure 3.9: The axiomatization of McCarthy’s Theory of Arrays.

additional symbolic variable. The call select(0,Var,H) now expressesthat “Var is equal to the 0th element in the vector H”. This allows a heap tobe expressed as a series of partially applied stores and selects.

The heap compilation procedure compiles from our new definition into aset of selects and one vector with McCarthy’s original functions as describedin Algorithm 1.

((select 0 X) ((store 0 5) EmptyHeap))

Figure 3.10: Example store expressed using s-expressions.

This representation comes at the cost of allocating a new symbolic variablefor each select done, which may increase the pressure on the SMT solver,we have not investigated any potential performance downsides related to this.The advantage comes from being very simple to compile to SMT-code for usein discharging to an SMT solver.


1: function CompileHeap(heap, stmts = ∅, lastHeap = emptyHeap)2: match heap3: case store(from,to)(innerHeap)4: CompileHeap(innerHeap, stmts,

store_M(latestHeap,from,to))5: end case6: case select(from)(innerHeap)7: CompileHeap(innerHeap ,stmts ∪ select_M(latestHeap),

latestHeap)8: end case9: case emptyHeap10: return stmts, latestHeap11: end case12: end match13: end functionAlgorithm 1: Compilation of heap into McCarthy’s definition.

3.2.2 Symbolic semanticsWith the basics explained we may now consider the symbolic semantics ofWebAssembly. The type of the symbolic reduction relation is changed fromConfig → Config into Config∗ → Config∗, this is in order to supportnon-determinism while keeping the reduction rules deterministic.

The rules [Block], [Label-value], [Label-br], and [Loop] are identical totheir current definitions, with the only change being that their reduction isdone inside of an EE evaluation context, therefore these are not needed to beshown.


EE[(mem ; E[((i32.const c0) (i32.const c1) op0 e*)] ; pc Config*)] [Operation]

EE[(mem ; E[((i32.const sym-var) e*)]

(sym-var = c0 op c1 pc) Config*)]

where op = translate-op⟦op0⟧, sym-var fresh

EE[(mem ; E[((i32.const c) (i32.load offset) e*)] ; pc Config*)] [Load]

EE[((meminst mem) ; E[((i32.const sym-var-loaded) e*)] ; (constrnooverlap pc) Config*)]

where meminst = (select offset + c sym-var-loaded), constrnooverlap = (o + c)(mod 4) = 0, sym-var-loaded fresh

EE[(mem ; E[((i32.const c0) (i32.const c1) (i32.store offset) e*)] ; pc Config*)] [Store]

EE[((meminst mem) ; E[e*] ; (constrnooverlap pc) Config*)]

where meminst = (store offset + c0 c1), constrnooverlap = (offset + c0)(mod 4) = 0

EE[(mem ; E[((const t c) (if then tf e*thn else e*els) e*)] ; pc Config*)] [If]

EE[(mem ; E[((block tf e*els) e*)] ; (c = 0 pc)

mem ; E[((block tf e*thn) e*)] ; (c ≠ 0 pc)

Config*)]

Figure 3.11: Symbolic semantics of WebAssembly.

The first two rules, [Operation] and [Load], are now symbolic in that theyallocate fresh variables.

For [Operation] a syntactic object representing the operation to be per-formed (where translate-op : op → ArithmOp) of each operation is recordedas an equality constraint on the fresh symbolic variable which is added to thepath condition. For [Load] it is recorded in the store, and the syntactic objectsare only select or store expressions.

An additional constraint is added to the path condition in both [Load] and[Store] to ensure that memory accesses are only made on 4-byte boundaries.Without such a constraint the complexity of encoding a path condition for aSMT solver would increase. This is because otherwise a 32-bit integer mightbe changed on its 16th bit and upwards, forcing us to represent integers asfixed-width bit vectors in the SMT solver instead as members of Z.

The [If] rule is the sole producer of non-determinism in symbolic We-bAssembly. It reduces to two configurations, one where the branch conditionis constrained to be exactly 0 in the path condition, and one where it is strictlygreater than 0. This is where the introduction of Config∗ becomes relevant.Now two configurations have been produced, and both will have to be reduceduntil they are final.

In some cases it can be deduced that exactly one of these branches will betaken, and if so it must be safe to discard the other configuration. This, andthe need for stating logical pre- and post-conditions of a program which canbe verified, leads to the introduction of a SMT solver which may verify such


assertions.

3.2.3 Discharging to SMT solverWe discharge to the SMT solver by computing a source-translation from thestore and path condition assertions of a configuration to the SMT-LIB languageas defined by Barrett et al. [29].

This translation exposes a set of variables which allow for access to theinitial and final heap and the individual stack elements after a small-step re-duction has occurred (if any are available). These variables are used by thepre- and post-condition assertions during verification.

Variable name Meaning Optionalheap The heap No

stack-n The nth stack value, 0 being the top, post-reduction Yes

Table 3.1: Variables available for usage in SMT-assertions.

The final-heap is expressed in terms of heap by asserting that it isequal to a set of stores performed in series on heap.

The stack-n variables are only gathered until a non-value is found onthe stack.

Each configuration can be checked if it has a satisfying assignment. If nosuch assignment exists, then there cannot possibly exist a concrete configura-tion which the symbolic configuration represents and therefore that configura-tion may be discarded.

Verification of an initial set of symbolic configurations C given a pre-condition P and a post-condition Q is done by:

1. Setting P as the initial path condition

2. Reducing the collection of configurations until only final states remain

3. Checking that Q is valid in each final configuration by searching for asatisfying assignment to ¬Q.

If a satisfying assignment to ¬Q is found then verification has failed. Ifit is shown to be unsatisfiable for all final configurations then verification hassucceeded.


3.2.4 Controlling state explosionNon-determinism leads to a growth of the number of configurations whichmust be reduced. As this increases, verification time also increases and assuch we would like to keep the increase of configurations as low as possible.

The advantage of WebAssembly’s control flow semantics become clearwith this in mind. WebAssembly has only a static branching operator, this isin contrast to for example the b instruction for the ARM instruction set. Suchan instruction takes a relative address as input which it unconditionally jumpsto (see the ARM instruction set manual [30]). The relative address might notbe concrete in a symbolic execution, and therefore the symbolic interpreterwill have to determine which values such an address can be (typically throughan SMT solver) and create exactly one new configuration for each of thesepossible values. This leads to extreme state explosion. Compare this to We-bAssembly, where each br instruction encodes which label depth to jump toand therefore does not lead to a growth in configurations.

3.3 Relational symbolic WebAssemblyAs in the preliminaries we will now define a relational interpreter for We-bAssembly. The major addition which we did not see in the preliminaries isthat this final interpreter will also be symbolic, yielding a relational symbolicinterpreter. These are the final semantics needed in order to perform verifica-tion of relational properties in WebAssembly.

We will now extend our symbolic WebAssembly grammar such that it iscapable of expressing relational programs. This will be done in two ways:

1. The stack is altered such that it consists of a pair of stacks, the left andthe right stack, encoding the two programs which relate to each other.

2. The heap is split into a left and right heap, correlating to the respectiveheap of each program.

The path condition is kept as one, the soundness of this decision is ex-panded upon in a later section.

The paired heap allows for projecting and merging stores in the same man-ner that was seen in the preliminaries.


b(pair meml memr)cleft ≡ meml

b(pair meml memr)cright ≡ memr

merge[meml, memr] ≡ (pair meml memr)

Figure 3.12: Projection and merging of a paired store, respectively.

rel.e* ::= (pair e* e*)

rel.mem ::= (pair mem

mem)

Cong ::= (rel.mem ; rel.e* ; pc)

Figure 3.13: Extended grammar for relational symbolic WebAssembly.

3.3.1 SemanticsIn Figure 3.14 the reduction rules are shown. Reductions of paired e∗ are doneby picking the appropriate projection to reduce next. Determining this is doneby inspection of each stack. What follows is a shorthand production of theserules, where the most specific rule is at the top. e∗l |e∗r is used as shorthand for(pair e∗l |e∗r) and the resulting reduction is noted by ′ next to it on the right-handside. The path condition, heap, and evaluation context is left implicit.

The [Step-if-left] and [Step-if-right] rules says that if an if instruction ison either side and the opposite is not an if then prioritize the non-if sidewhen reducing. This is not strictly necessary, but can instead be seen as anoptimisation. Since the non-if side may be entirely deterministic it is better tolet that reduce to a final state or until another branching instruction is reached.Assume that this choice was not made, and that the if side was reduced first,then the opposite side would have to be reduced twice for no practical gain.

The reductions of each stack projection is done by the symbolic interpreter.Earlier it was said that the path condition is kept unary. This is sound becausethe symbolic variables allocated for each projection is kept entirely disjoint.That is, there are no name clashes, and therefore no constraints will be addedto the path condition which wouldn’t exist in a unary context.


cl(if e∗lT e∗lF )|cr(if e∗rT e

∗rF ) →

e∗lT ; cl > 0|e∗rT ; cr > 0, e∗lT ; cl > 0|e∗rF ; cr = 0,

e∗lF ; cl = 0|e∗rT ; cr > 0, e∗lF ; cl = 0|e∗rF ; cr = 0 [Step-if-if]v∗|cr(if e∗T e

∗F ) →

v∗|e∗T ; cr > 0, v∗|e∗F ; cr = 0 [Step-v|if]cl(if e∗T e

∗F )|v∗ →

e∗T ; cl > 0|v∗, e∗F ; cl = 0|v∗ [Step-if|v]

where cl e∗l |cr e∗r → e∗l ; constrl|e∗r; constrr ≡mem;E[(const i32 cl)e∗l ]|E[(const i32c)e∗r]; pc →mem;E[e∗l ]|E[e∗r]; (constrl(constrrpc))

e∗|(if...) → e∗′|(if...)][Step-if-right](if...)|e∗ → (if...)|e∗′[Step-if-left]e∗|v∗ → e∗′|v∗[Step-left]v∗|e∗ → v∗|e∗′[Step-right]e∗|e∗ → e∗′|e∗′Step-both]where e∗l |e∗r → e∗l

′|e∗r ′ ≡mem;El[e

∗l ]|Er[e

∗r]; pc → mem;El[e

∗l′]|Er[e

∗r′]; pc

Figure 3.14: Relational symbolic WebAssembly semantics

3.3.2 Discharge to SMT solver re-visitedSince the stack and store are now split in two the source translation for theSMT solver must be adapted. Now variables for the left, respectively rightmemories are generated.

The stack collection now recurs into a pair instruction to further gatherleft and right values.


Variable name Meaning Optionalleft-heap The left heap No

right-heap The right heap Noleft-stack-n The nth stack value, 0 being the top, post-reduction Yes

right-stack-n The nth stack value, 0 being the top, post-reduction Yes

3.3.3 Stepping and collecting configurationsThe verification of a pre-condition, P , an initial configuration, C, and a post-condition, Q, is computed through the procedure described below.

First the SMT solver checks that the pre-condition is valid for the program.The SMT solver is run on each configuration, keeping only the ones which

are considered satisfiable.The function which steps once is defined as follows (with→ being applied

in a prefix position):

SAT − step(Config∗) = Config|Config ∈ (→ Config∗)

where SAT?(Config) ∨ final?(Config)

This can then be run until reaching fixpoint, at which point all satisfiablefinal configurations will have been collected. Such a set of final configurationsare then checked for satisfiability of the negation of the post-condition (thuschecking that the post-condition is valid).

If all final configurations are found to be valid then we can establish thatour verification is sound with regards to C, in other words:

if C ⇒ P ∧ Fix(SAT − step(C))⇒ Q then |= PCQ.

Chapter 4

Results

4.1 Implementation and runtime environmentThe relational symbolic interpreter is defined for a larger fragment of We-bAssembly and as such supports more features than the core fragment whichwe have explored in the report. In the case studies we will be utilizing globals,which are simply indices into a 0-indexed vector appended to the configura-tion. The larger grammar which our tool supports is available as an appendix.All of the limitations in the list 3.1 still hold.

It is written in the Racket programming language using the Redex libraryintroduced by Felleisen et al. [31]. The implementation is approximately2kLoC with 1k of those being the interpreter itself. The code is available athttps://github.com/jsjolen/relsym-wasm. It uses the Z3 SMTsolver [21]. The interpreter was adapted from a concrete model designed byAsumu Takikawa 1, which in turn was a direct adaptation of the semantics pro-duced in Rossberg et al. [25]. Unit tests were written for a large subset of thereduction rules and are available in the repository. All case studies are alsoavailable. All assertions are written in the SMT-LIB language.

The case studies were executed on a i7-7600U CPU with a set clock rateof 2.8GHz and 16GB of DDR4 SDRAM clocked at 2133 MHz.

4.2 Case studiesWe have considered two relational properties and applied them to real worlduse cases: program equivalence and non-interference.

1Original available here: https://github.com/takikawa/wasm-redex

36


CHAPTER 4. RESULTS 37

Program equivalence asserts that two programs P and P ′ agree on thefinal configuration of any initial configuration. The exact definition is as seenin Definition 2

Definition 2. Program equivalence. Two programs P , P ′ are equivalent ifand only if

∀M,M ′ ∈ Memory.M ⇒P M′ ⇐⇒ M ⇒P ′ M ′

where ⇒P refers to the reduction semantics over P . M ∈ Memory is aconfiguration formally described as (M, ε, [], ε). That is, it has a storeM , anempty frame, a hole (which can be plugged for reduction) and an empty pathcondition.

Given a set of private and public variables, also called the high respec-tively low variables, then non-interference means that the value of the publicvariables do not depend on the value of the private variables. This can beexpressed as seen in Definition 3.

Definition 3. Non-interference. A program P is non-interfering if and only if

∀M1,M′1,M2,M

′2 ∈ Memory.

M1(low) =M2(low)∧M1 ⇒P M

′1∧

M2 ⇒P M′2 ⇒

M ′1(low) =M ′

2(low)

In adapting the definitions of non-interference and program equivalence toWebAssembly we replace the memories with stores consisting of a heap andvector of globals.

4.2.1 Program equivalenceWe will consider two programs to be equal if and only if their final globals,heaps and stacks are the same. Note that both the number of globals and num-ber of stack elements left at the end of execution is known statically thanks to

38 CHAPTER 4. RESULTS

1 ( assert (= final -left - heap final - right -heap ))

2 ( assert (= left -glob -var -0 right -glob -var -0) )

3 ( assert (= left - stack -0 right - stack -0) )

Figure 4.1:

Figure 4.2: Program equivalence assertion.

WebAssembly’s typesystem. For simplicity’s sake we limit ourselves to pro-grams using one global and leaving one value on the stack. This is not aninherent limitation to our tool, it’s a limitation meant to ease readability of thefollowing case studies.

Any of the assertions may be omitted if it is irrelevant to the specific ex-ample at hand.

We did two small tests where we asked our tool if two small programs wereequivalent to each other by utilizing the post-condition listed in Figure 4.1.The programs are shown as both pseudo-code in a language similar to Whileand in WebAssembly. Our tool had no issue verifying either of the tests.

Constant conditional branch

If a program’s test condition for a branch always has the same outcome thenan optimization is to replace the branching with the branch which is alwaystaken.

As such the following transformation is correct.

1 x = 0;2 if(x) 3 y = 1;4 else 5 y = 2;6 7 Transformed into8 y = 2

Figure 4.3: Constant conditional branch, pseudo code.


Its equivalent WebAssembly transformation is the following.

1 i32 . const 02 (if [] -> [ i32 ]3 then4 i32 . const 15 else6 i32 . const 2)7 Transformed into8 i32 . const 2

Figure 4.4: Constant conditional branch, WebAssembly.

Unrolling loop equivalence

If it can be determined that a loop will run a set number of times then oneoptimization is to unroll the loop.

1 i = 3;2 while (i > 0) 3 x = x + 14 i = i - 1;5 6 Transformed into7 x = x+3

Figure 4.5: Unrolling loop equivalence, pseudo code.


4.2.2 Non-interferenceFor non-interference we will present a number of interfering programs andnon-interfering programs which shows the capabilities of our tool. Bytes 0-3are considered secret (the first 32-bit integer) while bytes 4-64 are consideredpublic. The initial public heap is considered to be zero:ed out.

We alter the above given definition to suit our specific use-case and say thatfor any initial and final configuration the assertion in Figure 4.7 must hold.


1 i32 . const 32 i32 .set - global 03 ( loop [] -> []4 i32 . const 35 i32 .get - global 06 i32 . sub7 (if [] -> []8 then9 i32 . const 110 i32 .get - global 111 i32 . add12 i32 .set - global 113 else14 (br 2))15 (br 0))16 Transformed into17 i32 . const 318 i32 .get - global 119 i32 . add20 i32 .set - global 1

Figure 4.6: Unrolling loop equivalence, WebAssembly.

∀x ∈ [4, 64].H[x] == H ′[x]

Figure 4.7: Non-interference specification for case studies.

Since an SMT solver only can deliver satisfiable results and not valid re-sults we will instead ask for a counter-example. That is, we instead ask for thenegation as seen in Figure 4.8.

¬∀x ∈ [4, 64].H[x] == H ′[x]

Figure 4.8: Negation of specification.

We found that performance of the SMT solver degraded significantly to


the point of being unusable when introducing a forall quantifier. As such wechose to manually unroll our formula into a series of negations which are dis-juncted. This improved performance significantly and allowed for verificationof our case studies. A simple proof that this is a correct transformation forquantification over a finite set is as seen in the proof below ( 4.9).

Proof.

¬∀x ∈ S.P (x)def.∀≡

¬(P (S1) ∧ P (S2) ∧ ... ∧ P (Si))DeMorgan′s≡

¬P (S1) ∨ ¬P (S2) ∨ ... ∨ ¬P (Si)

, |S| = i

Figure 4.9: Proof of equivalence.

The following condition is asserted on all initial and final configurations:

1 ( a s s e r t Ensure the initial heap is zeroed2 ( f o r a l l ( ( x I n t ) )3 (=> ( and ( < x 65) ( > x 3) )4 ( and5 (= ( s e l e c t l e f t heap x ) 0 )6 (= ( s e l e c t r i g h t heap x ) 0 ) ) ) ) )7 ( a s s e r t Post-condition8 ( o r ( no t (= ( s e l e c t f i n a l l e f t heap 4)9 ( s e l e c t f i n a l r i g h t heap 4) ) )

10 ... And so on11 ( no t (= ( s e l e c t f i n a l l e f t heap 63)12 ( s e l e c t f i n a l r i g h t heap 63) ) )13 ( no t (= ( s e l e c t f i n a l l e f t heap 64)14 ( s e l e c t f i n a l r i g h t heap 64) ) ) ) )

Figure 4.10: Pre- and post-condition for the non-interference case study.

The program is parametrically defined as:

1 ( pair ([] -> []) P P)


where P is the actual program which we will be expanding.The SMT-generated counter examples are available as an appendix.

Non-interference 1

The following works as expected. That is, storing a value from the secret partof the heap into the public part of the heap will fail.

1 H [4] = H [0] + 5

Figure 4.11: Non-interference 1, pseudo code.


1 i32 . const 4 Address for final store2 i32 . const 53 i32 . const 0 Address for load4 i32 . load 0 heap[0]5 i32 . add6 i32 . store

Figure 4.12: Non-interference 1, WebAssembly.

Non-interference 2

We have two final configurations, since sym-var-unknown is abstract bothbranches of the if are considered valid. Consider the branches, only one ofthemwill be interfering (the else-branch), however that is enough since at leastone final configuration will provide a counter-example from the SMT solver.

1 x := H [0] + 52 if(sym -var - unknown ) 3 return := x+44 else 5 H [4] = x6




1 i32 . const 42 i32 . const 53 i32 . const 04 i32 . load 0 05 i32 . add6 i32 . const sym -var - unknown7 (if ([ i32 i32 ] -> [])8 then9 i32 . add

10 else11 i32 . store 0 0)12


Non-interference 3

The following non-interfering program shows an advantage in using a rela-tional symbolic execution as compared to a type system based solution. Hereour tool can effectively determine that even though a low value is altered by ahigh value there will be no visible effect. A simple coloring typesystem wouldfail to recognize the non-interference of this program.

1 if(H [0] == 0) H [4] += H [0];




1 i32 . const 02 i32 . load 0 0 H[0]93 i32 . const 04 i32 .eq5 (if ([] -> [])6 then7 ( seq8 i32 . const 49 i32 . const 010 i32 . load 0 0 H[0]11 i32 . const 412 i32 . load 0 0 H[4]13 i32 . add14 i32 . store 0 0))15


4.2.3 StatisticsThe timings and number of calls out to the SMT solver are presented as anaverage of 50 runs of each test. As can be seen the time taken calling the SMTsolver is the majority of the time needed for finishing a verification.

Test name Total time elapsed (ms) SMT time elapsed (ms) SMT-callsN-inter 1 505 481 6N-inter 2 1672 1545 21N-inter 3 974 953 11P-equiv 1 454 449 6P-equiv 2 965 915 11

4.2.4 Constant-time WASMWewill now extend our work such that it is capable of capturing constant-timeexecution properties. Constant-time programs ensure that no side-channeltiming attacks can be made. Timing attacks utilize measuring timings between(for example) calls to functions to gain some information regarding secret vari-ables. In terms of the non-interference terminology based on secret and publicvariables we say that a constant-time program does not branch on secrets, does


not do heap stores or loads where the index depends on a secret, and does notdo pre-defined unsafe operations with secrets as input.

We will formalize this intuition of constant time WebAssembly similarlyto Watt et al. [3] by constructing a leakage model using the same concept thatis presented by Almeida et al. [32].

That is, we define a functionL : UnaryConfiguration→ Observation∗

which reports the public observations for a configuration. This function is ex-tended to deterministic executions c1c2c3...cn by asserting thatL(c1c2c3...cn) =L(c1)L(c2)L(c3)...L(cn).

We will now further explore the definition of our leakage model.

Leakage model

In order to check for constant time a leakage model L must be defined. Ourchoice of definition is inspired by Watt et al. [3] who in turn borrowed theirsfrom Almeida et al. [32]. The leakage model is described as:

“We adopt a leakage model which extends the leakiest model de-picted by [Almeida et al. 2016b], accounting for leakage of branchconditions, memory access patterns, and the operand sizes of un-safe binary operations, namely division and modulus.”

These choices may seem arbitrary, but they are based on real-world attacks.Consider for example the leakage of branch conditions. Attacks may be madeon the basis of indirect leakage of this data by utilizing branch mispredictionsby the CPU. See for example Acıiçmez et al. [33] which describes how topredict secret keys via branch prediction.

We collect the observations by projecting a configuration’s paired stackinto its left and right component and observing each separately. The full leak-age model definition is defined in Appendix C.

L⟦(s E[((const i32 c) (if then e*thn else e*els) e*)] pc)⟧ = (if (const i32 c))

L⟦(s E[((const i32 k) (load i32 o) e*)])⟧ = (load (+ o k))

Figure 4.17: Partial definition of the implemented leakage model.

Pure syntactic structural equivalence is inadequate since the operands ofan observation may be symbolic. Consider for example the two observationsin Figure 4.18.

Syntactic structural equivalence will report that these two observationsare not equal to each other, however if it is known by the path condition that


1 ( load (+ sym -var -x 1)) Left2 ( load 2) Right3

Figure 4.18: Two example observations.

sym-var-x = 1 then that conclusion is incorrect and they are in fact equiv-alent to each other. Therefore the observation operands will be checked forequivalence by discharging to a SMT solver.

Therefore given two sequences of observations of the same length j, obsland obsr, and a final configuration, conf , of a pair of programs, Pl and Pr, wesay that Pl and Pr are constant-time equivalent if and only if

SAT?(confpc ∧ ¬(j∧

i=0

obsil = obsir)) = false

That is, there is no satisfying assignment where some value may differbetween the left and right observation sequences, given that the path conditionholds.

Verifying Salsa20

Salsa20 is a stream cipher that is part of the TweetNacl toolkit. It was translatedinto WebAssembly and used by the CT-Wasm article to test their solution.

We will describe their specification and use it in order to verify the Salsa20cipher using our tool instead of theirs.

The types of the various variables used are declared as either secret orpublic. These type definitions acts as a formal specification for our leakagemodel.

The formal specification which CT-Wasm gives is as follows:

• Four public pointers into the heap are given as input (stored as locals)

• The heap is declared secret

• 32 secret locals are declared and initialized to 0

• 1 public local is declared and initialized to 0


CT-Wasm enforces that all memory indices used by load and store are pub-lic and that all stored values are secret if the heap is secret.

We enforce the formal specification by declaring that the input pointers beequal in the initial configuration. This is done by assigning the locals whichstores these intial values the same symbolic variables in each projection of theconfiguration. This is all which is necessary for verifying constant-time forSalsa20, now if our observations vary between any two runs we know it mustbe because of interference from the secret heap or secret local variables. Thereis no necessity to declare the heap secret as such, this is implied by leaving thecontent of the heap unspecified.

Let us consider a program where constant-time verification would fail forboth CT-Wasm and our formalization and why this is. We will let P be thelocal index to a public pointer.

1 i32 .get - local P

2 i32 . load 03 i32 .set - local P

4 i32 .get - local P

5 i32 . load 0

Since the local is public and it is set with a secret value this will fail ver-ification in CT-Wasm. In our tool this will fail because the second load maydiffer in the two runs. This is because the memory at heap index P is unde-fined and its content may therefore vary between the left and right run, leadingto a load (which our leakage model captures) which differs between the tworuns.

In order to use Salsa20 as a test program for our tool a semi-automatedtranslation fromWebAssembly text format into our abstract syntax tree formatwas required. This translation is available in Appendix D.

The Salsa20 program consists of 415 instructions of which 266 are part of aloop body which is repeated 10 times. That means that an approximate total of149+266∗10 = 2809 reductions are required to be computed by our tool. Theoriginal SAT − step function calls out to the SMT solver for each reductionmade, and as can be observed from the statistics the majority of time spentduring verification is inside of the SMT solver. Also observe that in order toterminate a loop if a condition is met the loop must contain an if instruction.Assuming that reducing SMT-calls will increase performance an optimizationtherefore is to only call out to the SMT solver when an if instruction hasjust reduced into its branches or when a configuration is final. Our tool maydo this optimization and the performance improvements for Salsa20 leads toapproximately 2.8 times faster execution. The verification was only run once.


• Salsa20 without if-opt (ms):cpu time: 159973 real time: 289754 gc time: 5105

• Salsa20 with if-opt (ms)cpu time: 56645 real time: 59023 gc time: 1965

The full leaked observations are available as an appendix, however let usconsider two pairs of observations from the appendix. Figure 4.19 showcasesthat the input variable $c does not differ since it is a public variable. If in-stead the variable was considered secret we would have separated the inputvariable into one for each side of the relational execution, sym-var-$c-land sym-var-$c-r, whose value may have differed. Figure 4.20 illustratesthe leakage of branching conditions. Here the symbolic variables differ, how-ever the path condition asserts that they must be equal.

1 Left : ( load (+ 12 sym -var -$c))2 Right : ( load (+ 12 sym -var -$c))

Figure 4.19: Observing a load instruction.

1 Left : ( const i32 sym -var -)2 Right : ( const i32 sym -var -32)

Figure 4.20: Observing a revealed condition.

Chapter 5

Discussion

5.1 Results and their limitationsThe results show that this tool can be used for proving relational properties ofpractical value. Especially the triviality of extending the relational interpreterwith a leakage model to observe different constant time properties shows thevalue in this work. Extending the work with more leakage models, specializedfor other forms of tracking, is quite easy to imagine.

This work has the potential to increase safety on the web. For example, thisallows developers themselves to ensure that their software cannot be compro-mised by an observing attacker by incorporating the tool into their toolchainin order to ensure that their compiled output is indeed constant time. Such ause case is the easiest to imagine, since only the developers themselves knowwhich parts of the heap, which variables, and so on are meant to be privateand which are public.

However, there are several limitationswith regards to the case studieswhichwe have constructed. For one, they are all quite small with fairly simple con-trol flow. Indeed, Salsa20 is designed to be cryptographically safe and as suchit represents a best case scenario for our tool, even though it is program size ison the order of hundreds of instructions.

The program equivalence property is of great importance for an optimiz-ing compiler, since re-writing one program to an equivalent one is how greaterperformance is yielded. However most compiler optimizations are done on anintermediate representation before machine code is generated. WebAssemblyis unlikely to be a suitable intermediate representation (IR) because of its staticcontrol flow, typically a graph based approach such as ‘sea of nodes’ is pre-ferred. This IR is what is re-written by optimizing compilers. The utility of

49

50 CHAPTER 5. DISCUSSION

checking semantic equivalence on the final output target may be smaller thanchecking semantic equivalence on the chosen IR since a compiler typicallycan generate output for several different platforms given one IR. Our tool maybe useful for peephole optimizers (as first introduced by McKeeman [34]),where sequence of instructions are pattern matched upon and replaced withmore performant alternatives.

5.2 Future work

5.2.1 Reimplementation for performanceAnother extension would be to reimplement the interpreter in a different pro-gramming language. A viable language would be OCaml since several otherformal verification tools have been implemented in this language and has shownitself to be empirically viable (see Farina et al. [13] for one such example).

5.2.2 Addition of featuresThe work presented in this thesis can be extended upon in several ways whichmay increase the capabilities of the interpreter which was reppresented in thiswork.

One such extension would be to make it complete with regards to the We-bAssembly semantics by extending the interpreters’ capabilities beyond only32-bit integers and supporting the full range ofWebAssembly data types. Thiswould mean that 32-bit and 64-bit floating point numbers along with 64-bit in-tegers would have to be supported. Along with this better support for loopsand recursive function calls could be done by implementing user-provided in-variants or invariant synthesis. Another such extension would be change theunderlying theory for the heap fromMcCarthy’s theory of arrays[28] to separa-tion logic as presented by Reynolds in [35]. Separation logic has seen industryuse in tools such as FB Infer and may be a better fit to express more complexproperties regarding the heap. Consider the non-interference case study wherewe had to iterate the bytes of the heap which were secret, with separation logicwe might be able to prove that only certain parts of the heap is accessed andtherefore succesfully avoid having to iterate over too many bytes for the SMTsolver to handle. Completely skipping the unrolling of the heap would alsobe very beneficial, and a lot of work has gone into SMT solvers implement-ing different kinds of so called quantifier instantiation, which are essentially

CHAPTER 5. DISCUSSION 51

heuristics for handling quantifiers in certain cases. Compiling down asser-tions such that these heuristics are applicable we hypothesize would be greatfor performance.

We believe that in order to be considered a feasible tool it is necessary forthe verification to be done in reasonable execution time (order of minutes) notonly on hand-written WebAssembly but also WebAssembly output by com-pilers. To test programs compiled into WebAssembly would therefore be ofinterest.

Chapter 6

Conclusions

We have selected a fragment of WebAssembly and formalized relational sym-bolic execution for that fragment. As such the question whether relationalsymbolic execution can be formalzed to a fragment of WebAssembly is yes.

We then extended this fragment and implemented a tool which performsrelational symbolic execution on this fragment. We evaluated this tool by per-forming both verification of program equivalence and non-interference for ba-sic programs and verification of constant-time security for the Salsa20 cipher.Therefore we have implemented and evaluated a relational symbolic executionfor a substantial fragment of WebAssembly.

We compared the Salsa20 verification with our tool to the verification per-formed by CT-Wasm. While CT-Wasm was faster our tool still has advan-tages, particularly as it may split the heap into private and public parts whichCT-Wasm is unable to do. Thus we have taken into account how relationalsymbolic execution compares to one existing method for WebAssembly.

We believe that extending the semantics to the fullWebAssembly languageand implementing it in a more performant language would be a worthy effort.

52

Bibliography

[1] asm.js in Firefox Nightly. https://blog.mozilla.org/luke/2013/03/21/asm-js-in-firefox-nightly/. Accessed:2020-06-09.

[2] Emscripten. https://emscripten.org/. Accessed: 2020-06-09.

[3] Conrad Watt et al. “CT-Wasm: Type-Driven Secure Cryptography forthe Web Ecosystem”. In: CoRR abs/1808.01348 (2018). arXiv: 1808.01348. url: http://arxiv.org/abs/1808.01348.

[4] Conrad Watt et al. “A Program Logic for First-Order Encapsulated We-bAssembly”. In: CoRR abs/1811.03479 (2018). arXiv: 1811.03479.url: http://arxiv.org/abs/1811.03479.

[5] Spectre Meltdown.https://meltdownattack.com/. Accessed:2020-06-16.

[6] C. A. R. Hoare. “An Axiomatic Basis for Computer Programming”. In:Commun. ACM 12.10 (Oct. 1969), pp. 576–580. issn: 0001-0782. doi:10.1145/363235.363259. url: https://doi.org/10.1145/363235.363259.

[7] G. Barthe, P. R. D’Argenio, and T. Rezk. “Secure information flow byself-composition”. In:Proceedings. 17th IEEEComputer Security Foun-dations Workshop, 2004. 2004, pp. 100–114.

[8] Gilles Barthe, Juan Manuel Crespo, and César Kunz. “Relational Veri-fication Using Product Programs”. In: FM 2011: Formal Methods. Ed.by Michael Butler and Wolfram Schulte. Berlin, Heidelberg: SpringerBerlin Heidelberg, 2011, pp. 200–214. isbn: 978-3-642-21437-0.

[9] H. B. Curry. “Functionality in Combinatory Logic”. In: Proceedings ofthe National Academy of Science 20.11 (Nov. 1934), pp. 584–590. doi:10.1073/pnas.20.11.584.

53

https://blog.mozilla.org/luke/2013/03/21/asm-js-in-firefox-nightly/

https://blog.mozilla.org/luke/2013/03/21/asm-js-in-firefox-nightly/

https://emscripten.org/

https://arxiv.org/abs/1808.01348


http://arxiv.org/abs/1808.01348



https://meltdownattack.com/

https://doi.org/10.1145/363235.363259

https://doi.org/10.1145/363235.363259

https://doi.org/10.1145/363235.363259

https://doi.org/10.1073/pnas.20.11.584

54 BIBLIOGRAPHY

[10] Greg Morrisett et al. “From System F to Typed Assembly Language”.In: ACM Trans. Program. Lang. Syst. 21.3 (May 1999), pp. 527–568.issn: 0164-0925. doi: 10.1145/319301.319345. url: https://doi.org/10.1145/319301.319345.

[11] Nick Benton. “Simple Relational Correctness Proofs for Static Anal-yses and Program Transformations”. In: Proceedings of the 31st ACMSIGPLAN-SIGACT Symposium onPrinciples of Programming Languages(POPL ’04). ACM, Jan. 2004, p. 43.url:https://www.microsoft.com/en-us/research/publication/simple-relational-correctness - proofs - for - static - analyses - and -program-transformations/.

[12] M. Balliu, M. Dam, and G. L. Guernic. “ENCoVer: Symbolic Explo-ration for Information Flow Security”. In: 2012 IEEE 25th ComputerSecurity Foundations Symposium. 2012, pp. 30–44.

[13] Gian Pietro Farina, Stephen Chong, and Marco Gaboardi. “RelationalSymbolic Execution”. In:CoRR abs/1711.08349 (2017). arXiv: 1711.08349. url: http://arxiv.org/abs/1711.08349.

[14] Daniel J. Bernstein. “The Salsa20 Family of Stream Ciphers”. In: NewStream Cipher Designs: The eSTREAM Finalists. Ed. by Matthew Rob-shaw andOlivier Billet. Berlin, Heidelberg: Springer Berlin Heidelberg,2008, pp. 84–97. isbn: 978-3-540-68351-3. doi: 10.1007/978-3-540-68351-3_8. url: https://doi.org/10.1007/978-3-540-68351-3_8.

[15] Gordon Plotkin. “A Structural Approach to Operational Semantics”.In: J. Log. Algebr. Program. 60-61 (July 2004), pp. 17–139. doi: 10.1016/j.jlap.2004.05.001.

[16] Matthias Felleisen and Robert Hieb. “The Revised Report on the Syn-tactic Theories of Sequential Control and State”. In: Theor. Comput. Sci.103.2 (Sept. 1992), pp. 235–271. issn: 0304-3975. doi: 10.1016/0304- 3975(92)90014- 7. url: https://doi.org/10.1016/0304-3975(92)90014-7.

[17] Bernhard Beckert and Mattias Ulbrich. “Trends in Relational ProgramVerification”. In: Principled Software Development: Essays Dedicatedto Arnd Poetzsch-Heffter on the Occasion of his 60th Birthday. Ed. byPeter Müller and Ina Schaefer. Cham: Springer International Publish-ing, 2018, pp. 41–58. isbn: 978-3-319-98047-8. doi: 10.1007/978-

https://doi.org/10.1145/319301.319345

https://doi.org/10.1145/319301.319345

https://doi.org/10.1145/319301.319345

https://www.microsoft.com/en-us/research/publication/simple-relational-correctness-proofs-for-static-analyses-and-program-transformations/







https://doi.org/10.1007/978-3-540-68351-3_8

https://doi.org/10.1007/978-3-540-68351-3_8

https://doi.org/10.1007/978-3-540-68351-3_8

https://doi.org/10.1007/978-3-540-68351-3_8

https://doi.org/10.1016/j.jlap.2004.05.001

https://doi.org/10.1016/j.jlap.2004.05.001

https://doi.org/10.1016/0304-3975(92)90014-7

https://doi.org/10.1016/0304-3975(92)90014-7

https://doi.org/10.1016/0304-3975(92)90014-7

https://doi.org/10.1016/0304-3975(92)90014-7

https://doi.org/10.1007/978-3-319-98047-8_3

https://doi.org/10.1007/978-3-319-98047-8_3

https://doi.org/10.1007/978-3-319-98047-8_3

BIBLIOGRAPHY 55

3-319-98047-8_3. url: https://doi.org/10.1007/978-3-319-98047-8_3.

[18] Robert S. Boyer, Bernard Elspas, and Karl N. Levitt. “SELECT—a For-mal System for Testing and Debugging Programs by Symbolic Execu-tion”. In: SIGPLAN Not. 10.6 (Apr. 1975), pp. 234–245. issn: 0362-1340. doi: 10.1145/390016.808445. url: https://doi.org/10.1145/390016.808445.

[19] James C. King. “Symbolic Execution and Program Testing”. In: Com-mun. ACM 19.7 (July 1976), pp. 385–394. issn: 0001-0782. doi: 10.1145/360248.360252. url: https://doi.org/10.1145/360248.360252.

[20] Martin Davis and Hilary Putnam. “A Computing Procedure for Quan-tification Theory”. In: J. ACM 7.3 (July 1960), pp. 201–215. issn: 0004-5411. doi: 10.1145/321033.321034. url: https://doi.org/10.1145/321033.321034.

[21] LeonardoDeMoura andNikolaj Bjørner. “Z3: AnEfficient SMTSolver”.In: Proceedings of the Theory and Practice of Software, 14th Interna-tional Conference on Tools and Algorithms for the Construction andAnalysis of Systems. TACAS’08/ETAPS’08. Budapest, Hungary: Springer-Verlag, 2008, pp. 337–340. isbn: 3540787992.

[22] Microsoft Research. Z3. https://github.com/Z3Prover/z3.2020.

[23] Stephen A. Cook. “The Complexity of Theorem-Proving Procedures”.In: Proceedings of the Third Annual ACM Symposium on Theory ofComputing. STOC ’71. Shaker Heights, Ohio, USA: Association forComputingMachinery, 1971, pp. 151–158. isbn: 9781450374644. doi:10.1145/800157.805047. url: https://doi.org/10.1145/800157.805047.

[24] WebAssemblyWorkingGroup.WebAssemblyDesignGoals. 2017.url:https://webassembly.github.io/spec/core/intro/introduction.html#design-goals (visited on 03/02/2020).

[25] Andreas Rossberg et al. “Bringing theWeb up to SpeedwithWebAssem-bly”. In: Commun. ACM 61.12 (Nov. 2018), pp. 107–115. issn: 0001-0782. doi: 10.1145/3282510. url: https://doi.org/10.1145/3282510.

https://doi.org/10.1007/978-3-319-98047-8_3

https://doi.org/10.1007/978-3-319-98047-8_3

https://doi.org/10.1007/978-3-319-98047-8_3

https://doi.org/10.1007/978-3-319-98047-8_3

https://doi.org/10.1007/978-3-319-98047-8_3

https://doi.org/10.1145/390016.808445

https://doi.org/10.1145/390016.808445

https://doi.org/10.1145/390016.808445

https://doi.org/10.1145/360248.360252

https://doi.org/10.1145/360248.360252

https://doi.org/10.1145/360248.360252

https://doi.org/10.1145/360248.360252

https://doi.org/10.1145/321033.321034

https://doi.org/10.1145/321033.321034

https://doi.org/10.1145/321033.321034

https://github.com/Z3Prover/z3

https://doi.org/10.1145/800157.805047

https://doi.org/10.1145/800157.805047

https://doi.org/10.1145/800157.805047

https://webassembly.github.io/spec/core/intro/introduction.html#design-goals

https://webassembly.github.io/spec/core/intro/introduction.html#design-goals

https://doi.org/10.1145/3282510

https://doi.org/10.1145/3282510

https://doi.org/10.1145/3282510

56 BIBLIOGRAPHY

[26] A.K. Wright and M. Felleisen. “A Syntactic Approach to Type Sound-ness”. In: Information and Computation 115.1 (1994), pp. 38–94. issn:0890-5401. doi: https://doi.org/10.1006/inco.1994.1093. url: http://www.sciencedirect.com/science/article/pii/S0890540184710935.

[27] Corrado Böhm and Giuseppe Jacopini. “Flow Diagrams, Turing Ma-chines and Languages with Only Two Formation Rules”. In: Commun.ACM 9.5 (May 1966), pp. 366–371. issn: 0001-0782. doi: 10.1145/355592.365646.url:https://doi.org/10.1145/355592.365646.

[28] JohnMcCarthy. “ABasis for aMathematical Theory of Computation1)”.In: Computer Programming and Formal Systems. Ed. by P. Braffortand D. Hirschberg. Vol. 35. Studies in Logic and the Foundations ofMathematics. Elsevier, 1963, pp. 33–70. doi: https://doi.org/10.1016/S0049-237X(08)72018-4. url: http://www.sciencedirect.com/science/article/pii/S0049237X08720184.

[29] Clark Barrett, Pascal Fontaine, and Cesare Tinelli. The SMT-LIB Stan-dard: Version 2.6. Tech. rep. Available at www.SMT-LIB.org. De-partment of Computer Science, The University of Iowa, 2017.

[30] Arm Limited. Company. Arm Instruction Set. Arm Limited. Company,2018.

[31] Robert Bruce Findler Matthias Felleisen and Matthew Flatt. SemanticsEngineering with PLT Redex. MIT Press, 2009.

[32] Jose Bacelar Almeida et al. “VerifyingConstant-Time Implementations”.In: 25th USENIX Security Symposium (USENIX Security 16). Austin,TX: USENIX Association, Aug. 2016, pp. 53–70. isbn: 978-1-931971-32-4.url:https://www.usenix.org/conference/usenixsecurity16/technical-sessions/presentation/almeida.

[33] Onur Acıiçmez, Cetin Koc, and Jean-Pierre Seifert. “Predicting SecretKeys Via Branch Prediction”. In: Feb. 2007, pp. 225–242. doi: 10.1007/11967668_15.

[34] W. M. McKeeman. “Peephole Optimization”. In: Commun. ACM 8.7(July 1965), pp. 443–444. issn: 0001-0782. doi: 10.1145/364995.365000.url:https://doi.org/10.1145/364995.365000.

https://doi.org/https://doi.org/10.1006/inco.1994.1093

https://doi.org/https://doi.org/10.1006/inco.1994.1093

http://www.sciencedirect.com/science/article/pii/S0890540184710935

http://www.sciencedirect.com/science/article/pii/S0890540184710935

https://doi.org/10.1145/355592.365646

https://doi.org/10.1145/355592.365646

https://doi.org/10.1145/355592.365646

https://doi.org/10.1145/355592.365646

https://doi.org/https://doi.org/10.1016/S0049-237X(08)72018-4

https://doi.org/https://doi.org/10.1016/S0049-237X(08)72018-4

http://www.sciencedirect.com/science/article/pii/S0049237X08720184

http://www.sciencedirect.com/science/article/pii/S0049237X08720184

https://www.usenix.org/conference/usenixsecurity16/technical-sessions/presentation/almeida

https://www.usenix.org/conference/usenixsecurity16/technical-sessions/presentation/almeida

https://doi.org/10.1007/11967668_15

https://doi.org/10.1007/11967668_15

https://doi.org/10.1145/364995.365000

https://doi.org/10.1145/364995.365000

https://doi.org/10.1145/364995.365000

BIBLIOGRAPHY 57

[35] John C. Reynolds. “Separation Logic: A Logic for SharedMutable DataStructures”. In: Proceedings of the 17th Annual IEEE Symposium onLogic in Computer Science. LICS ’02. USA: IEEE Computer Society,2002, pp. 55–74. isbn: 0769514839.

58

APPENDIX A. FULL WEBASSEMBLY GRAMMAR 59

Appendix A

Full WebAssembly grammar

t ::= t-i

t-i ::= i32

t ::= (-> (t ...) (t ...))

::= (func t local (t ...) e*)

cl ::= (inst i)

(code )

e ::= unreachable

| nop

| drop

| select

| return

| (block t e*)

| (loop t e*)

| (if t e* else e*)

| (br i)

| (get-global i)

| (set-global i)

| (tee-global i)

| (get-local i)

| (set-local i)

| (tee-local i)

| (load t a o)

| (store t a o)

| current-memory

| grow-memory

| (b t-i)

| (re t-i)

e ::= e

| (const t c)

b ::= b

b ::= add | sub | mul | and | or | xor | eq | rotl

re ::= re

re ::= eq | ne | lt-s | gt-s | le-s | ge-s

e* ::= ϵ

| (e e*)

c ::= teier

i, j, l, k, m, n, a, o ::= integer

b ::= integer

m-mem ::= (memory n)

e-no-v ::= ....

| trap

| (label n e* e*)

| (local n i (v ...) e*)

| (call j)

| (call c)

ex ::= (export s)

mms ::= (select c c) | (store c c)

mem ::= ϵ

| (mms mem)

gs ::= (glob v ...)

fcs ::= (func c ...)

F ::= (v ...)

s ::= (mem gs fcs)

v ::= (const t c)

v ::= ϵ

| (v v)

E ::= []

| (v E)

| ((label n (e*) E) e*)

Appendix B

Case studies generated counterexamples

60

APPENDIX B. CASE STUDIES GENERATED COUNTER EXAMPLES61

Non-interference 1

1 ( model2 ( d e f i n e fun sym var ( ) I n t 2435)3 ( d e f i n e fun sym var l oaded1 ( ) I n t 2431)4 ( d e f i n e fun5 f i n a l l e f t heap6 ( )7 ( Array I n t I n t )8 ( lambda ( ( x !1 I n t ) )9 ( l e t ( ( a !1 ( i t e (= x !1 25) 0 ( i t e (= x !1 59) 0 ( i t e (= x !1 53) 0 66) ) ) ) )

10 ( l e t ( ( a !2 ( i t e (= x !1 46) 0 ( i t e (= x !1 42) 0 ( i t e (= x !1 28) 0 a ! 1 ) ) ) ) )11 ( l e t ( ( a !3 ( i t e (= x !1 29) 0 ( i t e (= x !1 54) 0 ( i t e (= x !1 64) 0 a ! 2 ) ) ) ) )12 ( l e t ( ( a !4 ( i t e (= x !1 63) 0 ( i t e (= x !1 4 ) 0 ( i t e (= x !1 56) 0 a ! 3 ) ) ) ) )13 ( l e t ( ( a !5 ( i t e (= x !1 65) 68 ( i t e (= x !1 0 ) 2430 ( i t e (= x !1 14) 0 a ! 4 ) ) ) ) )14 ( l e t ( ( a !6 ( i t e (= x !1 45) 0 ( i t e (= x !1 24) 0 ( i t e (= x !1 50) 0 a ! 5 ) ) ) ) )15 ( l e t ( ( a !7 ( i t e (= x !1 37) 0 ( i t e (= x !1 17) 0 ( i t e (= x !1 39) 0 a ! 6 ) ) ) ) )16 ( l e t ( ( a !8 ( i t e (= x !1 8 ) 2435 ( i t e (= x !1 43) 0 ( i t e (= x !1 51) 0 a ! 7 ) ) ) ) )17 ( l e t ( ( a !9 ( i t e (= x !1 18) 0 ( i t e (= x !1 26) 0 ( i t e (= x !1 62) 0 a ! 8 ) ) ) ) )18 ( l e t ( ( a !10 ( i t e (= x !1 27) 0 ( i t e (= x !1 47) 0 ( i t e (= x !1 57) 0 a ! 9 ) ) ) ) )19 ( l e t ( ( a !11 ( i t e (= x !1 23) 0 ( i t e (= x !1 61) 0 ( i t e (= x !1 15) 0 a ! 1 0 ) ) ) ) )20 ( l e t ( ( a !12 ( i t e (= x !1 20) 0 ( i t e (= x !1 41) 0 ( i t e (= x !1 48) 0 a ! 1 1 ) ) )

) )21 ( l e t ( ( a !13 ( i t e (= x !1 22) 0 ( i t e (= x !1 34) 0 ( i t e (= x !1 31) 0 a ! 1 2 )

) ) ) )22 ( l e t ( ( a !14 ( i t e (= x !1 11) 0 ( i t e (= x !1 5 ) 0 ( i t e (= x !1 6 ) 0 a ! 1 3 )

) ) ) )23 ( l e t ( ( a !15 ( i t e (= x !1 10) 0 ( i t e (= x !1 44) 0 ( i t e (= x !1 35) 0 a

! 1 4 ) ) ) ) )24 ( l e t ( ( a !16 ( i t e (= x !1 16) 0 ( i t e (= x !1 9 ) 0 ( i t e (= x !1 32) 0

a ! 1 5 ) ) ) ) )25 ( l e t ( ( a !17 ( i t e (= x !1 58) 0 ( i t e (= x !1 33) 0 ( i t e (= x !1 19)

0 a ! 1 6 ) ) ) ) )26 ( l e t ( ( a !18 ( i t e (= x !1 60) 0 ( i t e (= x !1 21) 0 ( i t e (= x !1

12) 0 a ! 1 7 ) ) ) ) )27 ( l e t ( ( a !19 ( i t e (= x !1 49) 0 ( i t e (= x !1 55) 0 ( i t e (= x !1

13) 0 a ! 1 8 ) ) ) ) )28 ( l e t ( ( a !20 ( i t e (= x !1 36) 0 ( i t e (= x !1 30) 0 ( i t e (= x

!1 40) 0 a ! 1 9 ) ) ) ) ) ( i t e (= x !1 38) 0 ( i t e (= x !1 7 ) 0 ( i t e (= x !1 52) 0 a ! 2 0 ) ) ) ) ) ) ) ) ) ) ) ) ) ) ) ) ) ) ) ) )) ) ) )

29 ( d e f i n e fun30 r i g h t heap31 ( )32 ( Array I n t I n t )33 ( lambda ( ( x !1 I n t ) )34 ( l e t ( ( a !1 ( i t e (= x !1 28) 0 ( i t e (= x !1 7 ) 0 ( i t e (= x !1 38) 0 67) ) ) ) )35 ( l e t ( ( a !2 ( i t e (= x !1 46) 0 ( i t e (= x !1 42) 0 ( i t e (= x !1 25) 0 a ! 1 ) ) ) ) )36 ( l e t ( ( a !3 ( i t e (= x !1 29) 0 ( i t e (= x !1 54) 0 ( i t e (= x !1 64) 0 a ! 2 ) ) ) ) )37 ( l e t ( ( a !4 ( i t e (= x !1 63) 0 ( i t e (= x !1 4 ) 0 ( i t e (= x !1 56) 0 a ! 3 ) ) ) ) )38 ( l e t ( ( a !5 ( i t e (= x !1 65) 69 ( i t e (= x !1 0 ) 2431 ( i t e (= x !1 14) 0 a ! 4 ) ) ) ) )39 ( l e t ( ( a !6 ( i t e (= x !1 45) 0 ( i t e (= x !1 24) 0 ( i t e (= x !1 50) 0 a ! 5 ) ) ) ) )40 ( l e t ( ( a !7 ( i t e (= x !1 37) 0 ( i t e (= x !1 17) 0 ( i t e (= x !1 39) 0 a ! 6 ) ) ) ) )41 ( l e t ( ( a !8 ( i t e (= x !1 62) 0 ( i t e (= x !1 43) 0 ( i t e (= x !1 51) 0 a ! 7 ) ) ) ) )42 ( l e t ( ( a !9 ( i t e (= x !1 18) 0 ( i t e (= x !1 26) 0 ( i t e (= x !1 8 ) 0 a ! 8 ) ) ) ) )43 ( l e t ( ( a !10 ( i t e (= x !1 27) 0 ( i t e (= x !1 47) 0 ( i t e (= x !1 57) 0 a ! 9 ) ) ) ) )44 ( l e t ( ( a !11 ( i t e (= x !1 23) 0 ( i t e (= x !1 61) 0 ( i t e (= x !1 15) 0 a ! 1 0 ) ) ) ) )45 ( l e t ( ( a !12 ( i t e (= x !1 20) 0 ( i t e (= x !1 41) 0 ( i t e (= x !1 48) 0 a ! 1 1 ) ) )









!1 40) 0 a ! 1 9 ) ) ) ) ) ( i t e (= x !1 59) 0 ( i t e (= x !1 30) 0 ( i t e (= x !1 52) 0 a ! 2 0 ) ) ) ) ) ) ) ) ) ) ) ) ) ) ) ) ) ) ) )) ) ) ) )

54 ( d e f i n e fun55 f i n a l r i g h t heap56 ( )57 ( Array I n t I n t )

62 APPENDIX B. CASE STUDIES GENERATED COUNTEREXAMPLES

58 ( lambda ( ( x !1 I n t ) )59 ( l e t ( ( a !1 ( i t e (= x !1 25) 0 ( i t e (= x !1 59) 0 ( i t e (= x !1 53) 0 67) ) ) ) )60 ( l e t ( ( a !2 ( i t e (= x !1 46) 0 ( i t e (= x !1 42) 0 ( i t e (= x !1 28) 0 a ! 1 ) ) ) ) )61 ( l e t ( ( a !3 ( i t e (= x !1 29) 0 ( i t e (= x !1 54) 0 ( i t e (= x !1 64) 0 a ! 2 ) ) ) ) )62 ( l e t ( ( a !4 ( i t e (= x !1 63) 0 ( i t e (= x !1 4 ) 0 ( i t e (= x !1 56) 0 a ! 3 ) ) ) ) )63 ( l e t ( ( a !5 ( i t e (= x !1 65) 69 ( i t e (= x !1 0 ) 2431 ( i t e (= x !1 14) 0 a ! 4 ) ) ) ) )64 ( l e t ( ( a !6 ( i t e (= x !1 45) 0 ( i t e (= x !1 24) 0 ( i t e (= x !1 50) 0 a ! 5 ) ) ) ) )65 ( l e t ( ( a !7 ( i t e (= x !1 37) 0 ( i t e (= x !1 17) 0 ( i t e (= x !1 39) 0 a ! 6 ) ) ) ) )66 ( l e t ( ( a !8 ( i t e (= x !1 8 ) 2436 ( i t e (= x !1 43) 0 ( i t e (= x !1 51) 0 a ! 7 ) ) ) ) )67 ( l e t ( ( a !9 ( i t e (= x !1 18) 0 ( i t e (= x !1 26) 0 ( i t e (= x !1 62) 0 a ! 8 ) ) ) ) )68 ( l e t ( ( a !10 ( i t e (= x !1 27) 0 ( i t e (= x !1 47) 0 ( i t e (= x !1 57) 0 a ! 9 ) ) ) ) )69 ( l e t ( ( a !11 ( i t e (= x !1 23) 0 ( i t e (= x !1 61) 0 ( i t e (= x !1 15) 0 a ! 1 0 ) ) ) ) )70 ( l e t ( ( a !12 ( i t e (= x !1 20) 0 ( i t e (= x !1 41) 0 ( i t e (= x !1 48) 0 a ! 1 1 ) ) )









!1 40) 0 a ! 1 9 ) ) ) ) ) ( i t e (= x !1 38) 0 ( i t e (= x !1 7 ) 0 ( i t e (= x !1 52) 0 a ! 2 0 ) ) ) ) ) ) ) ) ) ) ) ) ) ) ) ) ) ) ) ) )) ) ) )

79 ( d e f i n e fun sym var l o aded ( ) I n t 2430)80 ( d e f i n e fun81 l e f t heap82 ( )83 ( Array I n t I n t )84 ( lambda ( ( x !1 I n t ) )85 ( l e t ( ( a !1 ( i t e (= x !1 28) 0 ( i t e (= x !1 7 ) 0 ( i t e (= x !1 38) 0 66) ) ) ) )86 ( l e t ( ( a !2 ( i t e (= x !1 46) 0 ( i t e (= x !1 42) 0 ( i t e (= x !1 25) 0 a ! 1 ) ) ) ) )87 ( l e t ( ( a !3 ( i t e (= x !1 29) 0 ( i t e (= x !1 54) 0 ( i t e (= x !1 64) 0 a ! 2 ) ) ) ) )88 ( l e t ( ( a !4 ( i t e (= x !1 63) 0 ( i t e (= x !1 4 ) 0 ( i t e (= x !1 56) 0 a ! 3 ) ) ) ) )89 ( l e t ( ( a !5 ( i t e (= x !1 65) 68 ( i t e (= x !1 0 ) 2430 ( i t e (= x !1 14) 0 a ! 4 ) ) ) ) )90 ( l e t ( ( a !6 ( i t e (= x !1 45) 0 ( i t e (= x !1 24) 0 ( i t e (= x !1 50) 0 a ! 5 ) ) ) ) )91 ( l e t ( ( a !7 ( i t e (= x !1 37) 0 ( i t e (= x !1 17) 0 ( i t e (= x !1 39) 0 a ! 6 ) ) ) ) )92 ( l e t ( ( a !8 ( i t e (= x !1 62) 0 ( i t e (= x !1 43) 0 ( i t e (= x !1 51) 0 a ! 7 ) ) ) ) )93 ( l e t ( ( a !9 ( i t e (= x !1 18) 0 ( i t e (= x !1 26) 0 ( i t e (= x !1 8 ) 0 a ! 8 ) ) ) ) )94 ( l e t ( ( a !10 ( i t e (= x !1 27) 0 ( i t e (= x !1 47) 0 ( i t e (= x !1 57) 0 a ! 9 ) ) ) ) )95 ( l e t ( ( a !11 ( i t e (= x !1 23) 0 ( i t e (= x !1 61) 0 ( i t e (= x !1 15) 0 a ! 1 0 ) ) ) ) )96 ( l e t ( ( a !12 ( i t e (= x !1 20) 0 ( i t e (= x !1 41) 0 ( i t e (= x !1 48) 0 a ! 1 1 ) ) )









!1 40) 0 a ! 1 9 ) ) ) ) ) ( i t e (= x !1 59) 0 ( i t e (= x !1 30) 0 ( i t e (= x !1 52) 0 a ! 2 0 ) ) ) ) ) ) ) ) ) ) ) ) ) ) ) ) ) ) ) )) ) ) ) )

105 ( d e f i n e fun sym var 2 ( ) I n t 2436) )

Non-interference 2

1 ( model2 ( d e f i n e fun sym var ( ) I n t 2435)3 ( d e f i n e fun sym var l oaded1 ( ) I n t 2431)4 ( d e f i n e fun5 f i n a l l e f t heap6 ( )7 ( Array I n t I n t )

APPENDIX B. CASE STUDIES GENERATED COUNTER EXAMPLES63

8 ( lambda ( ( x !1 I n t ) )9 ( l e t ( ( a !1 ( i t e (= x !1 25) 0 ( i t e (= x !1 59) 0 ( i t e (= x !1 53) 0 ( 1793) ) ) ) ) )

10 ( l e t ( ( a !2 ( i t e (= x !1 46) 0 ( i t e (= x !1 42) 0 ( i t e (= x !1 28) 0 a ! 1 ) ) ) ) )11 ( l e t ( ( a !3 ( i t e (= x !1 29) 0 ( i t e (= x !1 54) 0 ( i t e (= x !1 64) 0 a ! 2 ) ) ) ) )12 ( l e t ( ( a !4 ( i t e (= x !1 63) 0 ( i t e (= x !1 4 ) 0 ( i t e (= x !1 56) 0 a ! 3 ) ) ) ) )13 ( l e t ( ( a !5 ( i t e (= x !1 ( 8362) ) 66 ( i t e (= x !1 0 ) 2430 ( i t e (= x !1 14) 0 a ! 4 ) ) ) ) )14 ( l e t ( ( a !6 ( i t e (= x !1 24) 0 ( i t e (= x !1 50) 0 ( i t e (= x !1 ( 1793) ) 67 a ! 5 ) ) ) ) )15 ( l e t ( ( a !7 ( i t e (= x !1 17) 0 ( i t e (= x !1 39) 0 ( i t e (= x !1 45) 0 a ! 6 ) ) ) ) )16 ( l e t ( ( a !8 ( i t e (= x !1 43) 0 ( i t e (= x !1 51) 0 ( i t e (= x !1 37) 0 a ! 7 ) ) ) ) )17 ( l e t ( ( a !9 ( i t e (= x !1 26) 0 ( i t e (= x !1 62) 0 ( i t e (= x !1 8 ) 2435 a ! 8 ) ) ) ) )18 ( l e t ( ( a !10 ( i t e (= x !1 47) 0 ( i t e (= x !1 57) 0 ( i t e (= x !1 18) 0 a ! 9 ) ) ) ) )19 ( l e t ( ( a !11 ( i t e (= x !1 61) 0 ( i t e (= x !1 15) 0 ( i t e (= x !1 27) 0 a ! 1 0 ) ) ) ) )20 ( l e t ( ( a !12 ( i t e (= x !1 41) 0 ( i t e (= x !1 48) 0 ( i t e (= x !1 23) 0 a ! 1 1 ) ) )


) ) ) )22 ( l e t ( ( a !14 ( i t e (= x !1 5 ) 0 ( i t e (= x !1 6 ) 0 ( i t e (= x !1 22) 0 a ! 1 3 )


! 1 4 ) ) ) ) )24 ( l e t ( ( a !16 ( i t e (= x !1 9 ) 0 ( i t e (= x !1 32) 0 ( i t e (= x !1 10) 0





!1 49) 0 a ! 1 9 ) ) ) ) )29 ( l e t ( ( a !21 ( i t e (= x !1 7 ) 0 ( i t e (= x !1 52) 0 ( i t e (=

x !1 36) 0 a ! 2 0 ) ) ) ) ) ( i t e (= x !1 38) 0 a ! 2 1 ) ) ) ) ) ) ) ) ) ) ) ) ) ) ) ) ) ) ) ) ) ) ) )30 ( d e f i n e fun31 r i g h t heap32 ( )33 ( Array I n t I n t )34 ( lambda ( ( x !1 I n t ) )35 ( l e t ( ( a !1 ( i t e (= x !1 25) 0 ( i t e (= x !1 36) 0 ( i t e (= x !1 30) 0 65) ) ) ) )36 ( l e t ( ( a !2 ( i t e (= x !1 64) 0 ( i t e (= x !1 42) 0 ( i t e (= x !1 28) 0 a ! 1 ) ) ) ) )37 ( l e t ( ( a !3 ( i t e (= x !1 29) 0 ( i t e (= x !1 54) 0 ( i t e (= x !1 46) 0 a ! 2 ) ) ) ) )38 ( l e t ( ( a !4 ( i t e (= x !1 63) 0 ( i t e (= x !1 4 ) 0 ( i t e (= x !1 56) 0 a ! 3 ) ) ) ) )39 ( l e t ( ( a !5 ( i t e (= x !1 ( 8362) ) 68 ( i t e (= x !1 0 ) 2431 ( i t e (= x !1 14) 0 a ! 4 ) ) ) ) )40 ( l e t ( ( a !6 ( i t e (= x !1 24) 0 ( i t e (= x !1 50) 0 ( i t e (= x !1 ( 1793) ) 69 a ! 5 ) ) ) ) )41 ( l e t ( ( a !7 ( i t e (= x !1 17) 0 ( i t e (= x !1 39) 0 ( i t e (= x !1 45) 0 a ! 6 ) ) ) ) )42 ( l e t ( ( a !8 ( i t e (= x !1 43) 0 ( i t e (= x !1 51) 0 ( i t e (= x !1 37) 0 a ! 7 ) ) ) ) )43 ( l e t ( ( a !9 ( i t e (= x !1 26) 0 ( i t e (= x !1 8 ) 0 ( i t e (= x !1 62) 0 a ! 8 ) ) ) ) )44 ( l e t ( ( a !10 ( i t e (= x !1 47) 0 ( i t e (= x !1 57) 0 ( i t e (= x !1 18) 0 a ! 9 ) ) ) ) )45 ( l e t ( ( a !11 ( i t e (= x !1 27) 0 ( i t e (= x !1 15) 0 ( i t e (= x !1 61) 0 a ! 1 0 ) ) ) ) )46 ( l e t ( ( a !12 ( i t e (= x !1 41) 0 ( i t e (= x !1 48) 0 ( i t e (= x !1 23) 0 a ! 1 1 ) ) )










x !1 59) 0 a ! 2 0 ) ) ) ) ) ( i t e (= x !1 38) 0 a ! 2 1 ) ) ) ) ) ) ) ) ) ) ) ) ) ) ) ) ) ) ) ) ) ) ) )56 ( d e f i n e fun57 f i n a l r i g h t heap58 ( )59 ( Array I n t I n t )60 ( lambda ( ( x !1 I n t ) )61 ( l e t ( ( a !1 ( i t e (= x !1 25) 0 ( i t e (= x !1 59) 0 ( i t e (= x !1 53) 0 65) ) ) ) )62 ( l e t ( ( a !2 ( i t e (= x !1 46) 0 ( i t e (= x !1 42) 0 ( i t e (= x !1 28) 0 a ! 1 ) ) ) ) )63 ( l e t ( ( a !3 ( i t e (= x !1 29) 0 ( i t e (= x !1 54) 0 ( i t e (= x !1 64) 0 a ! 2 ) ) ) ) )64 ( l e t ( ( a !4 ( i t e (= x !1 63) 0 ( i t e (= x !1 4 ) 0 ( i t e (= x !1 56) 0 a ! 3 ) ) ) ) )65 ( l e t ( ( a !5 ( i t e (= x !1 ( 8362) ) 68 ( i t e (= x !1 0 ) 2431 ( i t e (= x !1 14) 0 a ! 4 ) ) ) ) )66 ( l e t ( ( a !6 ( i t e (= x !1 24) 0 ( i t e (= x !1 50) 0 ( i t e (= x !1 ( 1793) ) 69 a ! 5 ) ) ) ) )67 ( l e t ( ( a !7 ( i t e (= x !1 17) 0 ( i t e (= x !1 39) 0 ( i t e (= x !1 45) 0 a ! 6 ) ) ) ) )

64 APPENDIX B. CASE STUDIES GENERATED COUNTEREXAMPLES

68 ( l e t ( ( a !8 ( i t e (= x !1 43) 0 ( i t e (= x !1 51) 0 ( i t e (= x !1 37) 0 a ! 7 ) ) ) ) )69 ( l e t ( ( a !9 ( i t e (= x !1 26) 0 ( i t e (= x !1 62) 0 ( i t e (= x !1 8 ) 2436 a ! 8 ) ) ) ) )70 ( l e t ( ( a !10 ( i t e (= x !1 47) 0 ( i t e (= x !1 57) 0 ( i t e (= x !1 18) 0 a ! 9 ) ) ) ) )71 ( l e t ( ( a !11 ( i t e (= x !1 61) 0 ( i t e (= x !1 15) 0 ( i t e (= x !1 27) 0 a ! 1 0 ) ) ) ) )72 ( l e t ( ( a !12 ( i t e (= x !1 41) 0 ( i t e (= x !1 48) 0 ( i t e (= x !1 23) 0 a ! 1 1 ) ) )










x !1 36) 0 a ! 2 0 ) ) ) ) ) ( i t e (= x !1 38) 0 a ! 2 1 ) ) ) ) ) ) ) ) ) ) ) ) ) ) ) ) ) ) ) ) ) ) ) )82 ( d e f i n e fun sym var l o aded ( ) I n t 2430)83 ( d e f i n e fun84 l e f t heap85 ( )86 ( Array I n t I n t )87 ( lambda ( ( x !1 I n t ) )88 ( l e t ( ( a !1 ( i t e (= x !1 25) 0 ( i t e (= x !1 36) 0 ( i t e (= x !1 30) 0 ( 1793) ) ) ) ) )89 ( l e t ( ( a !2 ( i t e (= x !1 64) 0 ( i t e (= x !1 42) 0 ( i t e (= x !1 28) 0 a ! 1 ) ) ) ) )90 ( l e t ( ( a !3 ( i t e (= x !1 29) 0 ( i t e (= x !1 54) 0 ( i t e (= x !1 46) 0 a ! 2 ) ) ) ) )91 ( l e t ( ( a !4 ( i t e (= x !1 63) 0 ( i t e (= x !1 4 ) 0 ( i t e (= x !1 56) 0 a ! 3 ) ) ) ) )92 ( l e t ( ( a !5 ( i t e (= x !1 ( 8362) ) 66 ( i t e (= x !1 0 ) 2430 ( i t e (= x !1 14) 0 a ! 4 ) ) ) ) )93 ( l e t ( ( a !6 ( i t e (= x !1 24) 0 ( i t e (= x !1 50) 0 ( i t e (= x !1 ( 1793) ) 67 a ! 5 ) ) ) ) )94 ( l e t ( ( a !7 ( i t e (= x !1 17) 0 ( i t e (= x !1 39) 0 ( i t e (= x !1 45) 0 a ! 6 ) ) ) ) )95 ( l e t ( ( a !8 ( i t e (= x !1 43) 0 ( i t e (= x !1 51) 0 ( i t e (= x !1 37) 0 a ! 7 ) ) ) ) )96 ( l e t ( ( a !9 ( i t e (= x !1 26) 0 ( i t e (= x !1 8 ) 0 ( i t e (= x !1 62) 0 a ! 8 ) ) ) ) )97 ( l e t ( ( a !10 ( i t e (= x !1 47) 0 ( i t e (= x !1 57) 0 ( i t e (= x !1 18) 0 a ! 9 ) ) ) ) )98 ( l e t ( ( a !11 ( i t e (= x !1 27) 0 ( i t e (= x !1 15) 0 ( i t e (= x !1 61) 0 a ! 1 0 ) ) ) ) )99 ( l e t ( ( a !12 ( i t e (= x !1 41) 0 ( i t e (= x !1 48) 0 ( i t e (= x !1 23) 0 a ! 1 1 ) ) )










x !1 59) 0 a ! 2 0 ) ) ) ) ) ( i t e (= x !1 38) 0 a ! 2 1 ) ) ) ) ) ) ) ) ) ) ) ) ) ) ) ) ) ) ) ) ) ) ) )109 ( d e f i n e fun sym var unknown ( ) I n t 0 )110 ( d e f i n e fun sym var 2 ( ) I n t 2436) )

Non-interference 3

Non-interference 4

UNSAT

Appendix C

Leakage model

L⟦(s [((pair l[(trap e*l)]

r[(trap e*r)]) e*)]

p)⟧

= ((trap ϵ) (trap ϵ))

L⟦( [((pair l[((const tl l)

((if tl e*thn-l else e*el-l) e*l))]

r[((const tr r)

((if tr e*thn-r else e*el-r) e*r))])

e*)]

p)⟧

= (((const tl l) ϵ) ((const tr r) ϵ))

L⟦( [((pair l[((const tl l)

((if t e*thn else e*el) e*l))]

*r) e*)]

p)⟧

= (((const tl l) ϵ) ϵ)

L⟦( [ ((pair *l

r[((const tr r)

((if t e*thn else e*el) e*r))])

e*)]

p)⟧

= (ϵ ((const tr r) ϵ))

L⟦( [((pair e*l e*r) e*)] p)⟧ = (oberation*l oberation*r)

where oberation*l = L-helper⟦( [((pair e*l e*r) e*)] p), 1⟧, oberation*r = L-helper⟦( [((pair e*l e*r) e*)] p), 2⟧

L⟦any⟧ = (ϵ ϵ)

65

66 APPENDIX C. LEAKAGE MODEL

L-helper⟦(s

[((pair l[((const t !) ((load t a o) e*l))]

e*r)

e*)]

"!), 1⟧

= ((load (+ o !)) ϵ)

L-helper⟦(#

[((pair e*l

r[((const t !) ((load t a o) e*r))])

e*)]

"!), 2⟧

= ((load (+ o !)) ϵ)

L-helper⟦(#

[((pair l[((const t k) ((const t !) ((store t a o) e*l)))]

e*r)

e*)]

"!), 1⟧

= ((store (+ o k)) ϵ)

L-helper⟦(#

[((pair e*l

r[((const t k) ((const t !) ((store t a o) e*r)))])

e*)]

"!), 2⟧

= ((store (+ o k)) ϵ)

L-helper⟦(#

[((pair

l[((const t k) ((const t !) ((div t) e*l)))]

e*r)

e*)]

"!), 1⟧

= (div ϵ)

L-helper⟦(#

[((pair e*l

r[((const t k) ((const t !) ((div t) e*r)))])

e*)]

"!), 2⟧

= (div ϵ)

L-helper⟦an$l, an$r⟧ = ϵ

Appendix D

Salsa20 WebAssembly transla-tion

1 (get - global 3)2 ( load i32 0 12)3 (tee - global 35)4 (set - global 19)5 (get - global 2)6 ( load i32 0 28)7 (tee - global 34)8 (set - global 18)9 (get - global 2)

10 ( load i32 0 24)11 (tee - global 33)12 (set - global 17)13 (get - global 2)14 ( load i32 0 20)15 (tee - global 32)16 (set - global 16)17 (get - global 2)18 ( load i32 0 16)19 (tee - global 31)20 (set - global 15)21 (get - global 3)22 ( load i32 0 8)23 (tee - global 30)24 (set - global 14)

67

68 APPENDIX D. SALSA20 WEBASSEMBLY TRANSLATION

25 (get - global 1)26 ( load i32 0 12)27 (tee - global 29)28 (set - global 13)29 (get - global 1)30 ( load i32 0 8)31 (tee - global 28)32 (set - global 12)33 (get - global 1)34 ( load i32 0 4)35 (tee - global 27)36 (set - global 11)37 (get - global 1)38 ( load i32 0 0)39 (tee - global 26)40 (set - global 10)41 (get - global 3)42 ( load i32 0 4)43 (tee - global 25)44 (set - global 9)45 (get - global 2)46 ( load i32 0 12)47 (tee - global 24)48 (set - global 8)49 (get - global 2)50 ( load i32 0 8)51 (tee - global 23)52 (set - global 7)53 (get - global 2)54 ( load i32 0 4)55 (tee - global 22)56 (set - global 6)57 (get - global 2)58 ( load i32 0 0)59 (tee - global 21)60 (set - global 5)61 (get - global 3)62 ( load i32 0 0)63 (tee - global 20)

APPENDIX D. SALSA20 WEBASSEMBLY TRANSLATION 69

64 (set - global 4)65 ( block66 (-> () ())67 ( seq68 ( loop69 (-> () ())70 ( seq71 ( const i32 20)72 (get - global 36)73 ( sub i32 )74 (if (-> () ()) else ( seq (

br 2)))75 (get - global 19)76 (get - global 18)77 (get - global 17)78 ( add i32 )79 ( const i32 18)80 ( rotl i32 )81 ( xor i32 )82 (set - global 19)83 (get - global 18)84 (get - global 17)85 (get - global 16)86 ( add i32 )87 ( const i32 13)88 ( rotl i32 )89 ( xor i32 )90 (set - global 18)91 (get - global 17)92 (get - global 16)93 (get - global 19)94 ( add i32 )95 ( const i32 9)96 ( rotl i32 )97 ( xor i32 )98 (set - global 17)99 (get - global 16)

100 (get - global 19)101 (get - global 18)


102 ( add i32 )103 ( const i32 7)104 ( rotl i32 )105 ( xor i32 )106 (set - global 16)107 (get - global 14)108 (get - global 13)109 (get - global 12)110 ( add i32 )111 ( const i32 18)112 ( rotl i32 )113 ( xor i32 )114 (set - global 14)115 (get - global 13)116 (get - global 12)117 (get - global 15)118 ( add i32 )119 ( const i32 13)120 ( rotl i32 )121 ( xor i32 )122 (set - global 13)123 (get - global 12)124 (get - global 15)125 (get - global 14)126 ( add i32 )127 ( const i32 9)128 ( rotl i32 )129 ( xor i32 )130 (set - global 12)131 (get - global 15)132 (get - global 14)133 (get - global 13)134 ( add i32 )135 ( const i32 7)136 ( rotl i32 )137 ( xor i32 )138 (set - global 15)139 (get - global 9)140 (get - global 8)


141 (get - global 11)142 ( add i32 )143 ( const i32 18)144 ( rotl i32 )145 ( xor i32 )146 (set - global 9)147 (get - global 8)148 (get - global 11)149 (get - global 10)150 ( add i32 )151 ( const i32 13)152 ( rotl i32 )153 ( xor i32 )154 (set - global 8)155 (get - global 11)156 (get - global 10)157 (get - global 9)158 ( add i32 )159 ( const i32 9)160 ( rotl i32 )161 ( xor i32 )162 (set - global 11)163 (get - global 10)164 (get - global 9)165 (get - global 8)166 ( add i32 )167 ( const i32 7)168 ( rotl i32 )169 ( xor i32 )170 (set - global 10)171 (get - global 4)172 (get - global 7)173 (get - global 6)174 ( add i32 )175 ( const i32 18)176 ( rotl i32 )177 ( xor i32 )178 (set - global 4)179 (get - global 7)


180 (get - global 6)181 (get - global 5)182 ( add i32 )183 ( const i32 13)184 ( rotl i32 )185 ( xor i32 )186 (set - global 7)187 (get - global 6)188 (get - global 5)189 (get - global 4)190 ( add i32 )191 ( const i32 9)192 ( rotl i32 )193 ( xor i32 )194 (set - global 6)195 (get - global 5)196 (get - global 4)197 (get - global 7)198 ( add i32 )199 ( const i32 7)200 ( rotl i32 )201 ( xor i32 )202 (set - global 5)203 (get - global 19)204 (get - global 15)205 (get - global 11)206 ( add i32 )207 ( const i32 18)208 ( rotl i32 )209 ( xor i32 )210 (set - global 19)211 (get - global 15)212 (get - global 11)213 (get - global 7)214 ( add i32 )215 ( const i32 13)216 ( rotl i32 )217 ( xor i32 )218 (set - global 15)


219 (get - global 11)220 (get - global 7)221 (get - global 19)222 ( add i32 )223 ( const i32 9)224 ( rotl i32 )225 ( xor i32 )226 (set - global 11)227 (get - global 7)228 (get - global 19)229 (get - global 15)230 ( add i32 )231 ( const i32 7)232 ( rotl i32 )233 ( xor i32 )234 (set - global 7)235 (get - global 14)236 (get - global 10)237 (get - global 6)238 ( add i32 )239 ( const i32 18)240 ( rotl i32 )241 ( xor i32 )242 (set - global 14)243 (get - global 10)244 (get - global 6)245 (get - global 18)246 ( add i32 )247 ( const i32 13)248 ( rotl i32 )249 ( xor i32 )250 (set - global 10)251 (get - global 6)252 (get - global 18)253 (get - global 14)254 ( add i32 )255 ( const i32 9)256 ( rotl i32 )257 ( xor i32 )


258 (set - global 6)259 (get - global 18)260 (get - global 14)261 (get - global 10)262 ( add i32 )263 ( const i32 7)264 ( rotl i32 )265 ( xor i32 )266 (set - global 18)267 (get - global 9)268 (get - global 5)269 (get - global 17)270 ( add i32 )271 ( const i32 18)272 ( rotl i32 )273 ( xor i32 )274 (set - global 9)275 (get - global 5)276 (get - global 17)277 (get - global 13)278 ( add i32 )279 ( const i32 13)280 ( rotl i32 )281 ( xor i32 )282 (set - global 5)283 (get - global 17)284 (get - global 13)285 (get - global 9)286 ( add i32 )287 ( const i32 9)288 ( rotl i32 )289 ( xor i32 )290 (set - global 17)291 (get - global 13)292 (get - global 9)293 (get - global 5)294 ( add i32 )295 ( const i32 7)296 ( rotl i32 )


297 ( xor i32 )298 (set - global 13)299 (get - global 4)300 (get - global 16)301 (get - global 12)302 ( add i32 )303 ( const i32 18)304 ( rotl i32 )305 ( xor i32 )306 (set - global 4)307 (get - global 16)308 (get - global 12)309 (get - global 8)310 ( add i32 )311 ( const i32 13)312 ( rotl i32 )313 ( xor i32 )314 (set - global 16)315 (get - global 12)316 (get - global 8)317 (get - global 4)318 ( add i32 )319 ( const i32 9)320 ( rotl i32 )321 ( xor i32 )322 (set - global 12)323 (get - global 8)324 (get - global 4)325 (get - global 16)326 ( add i32 )327 ( const i32 7)328 ( rotl i32 )329 ( xor i32 )330 (set - global 8)331 ( const i32 2)332 (get - global 36)333 ( add i32 )334 (set - global 36)335 (br 0)))))


336 (get - global 0)337 (get - global 19)338 (get - global 35)339 ( add i32 )340 ( store i32 0 60)341 (get - global 0)342 (get - global 18)343 (get - global 34)344 ( add i32 )345 ( store i32 0 56)346 (get - global 0)347 (get - global 17)348 (get - global 33)349 ( add i32 )350 ( store i32 0 52)351 (get - global 0)352 (get - global 16)353 (get - global 32)354 ( add i32 )355 ( store i32 0 48)356 (get - global 0)357 (get - global 15)358 (get - global 31)359 ( add i32 )360 ( store i32 0 44)361 (get - global 0)362 (get - global 14)363 (get - global 30)364 ( add i32 )365 ( store i32 0 40)366 (get - global 0)367 (get - global 13)368 (get - global 29)369 ( add i32 )370 ( store i32 0 36)371 (get - global 0)372 (get - global 12)373 (get - global 28)374 ( add i32 )


375 ( store i32 0 32)376 (get - global 0)377 (get - global 11)378 (get - global 27)379 ( add i32 )380 ( store i32 0 28)381 (get - global 0)382 (get - global 10)383 (get - global 26)384 ( add i32 )385 ( store i32 0 24)386 (get - global 0)387 (get - global 9)388 (get - global 25)389 ( add i32 )390 ( store i32 0 20)391 (get - global 0)392 (get - global 8)393 (get - global 24)394 ( add i32 )395 ( store i32 0 16)396 (get - global 0)397 (get - global 7)398 (get - global 23)399 ( add i32 )400 ( store i32 0 12)401 (get - global 0)402 (get - global 6)403 (get - global 22)404 ( add i32 )405 ( store i32 0 8)406 (get - global 0)407 (get - global 5)408 (get - global 21)409 ( add i32 )410 ( store i32 0 4)411 (get - global 0)412 (get - global 4)413 (get - global 20)


414 ( add i32 )415 ( store i32 0 0)

Appendix E

Leaked observations

Left:

1 (( load (+ 12 sym -var -$c))2 (( load (+ 28 sym -var -$k))3 (( load (+ 24 sym -var -$k))4 (( load (+ 20 sym -var -$k))5 (( load (+ 16 sym -var -$k))6 (( load (+ 8 sym -var -$c))7 (( load (+ 12 sym -var -$p))8 (( load (+ 8 sym -var -$p))9 (( load (+ 4 sym -var -$p))

10 (( load (+ 0 sym -var -$p))11 (( load (+ 4 sym -var -$c))12 (( load (+ 12 sym -var -$k))13 (( load (+ 8 sym -var -$k))14 (( load (+ 4 sym -var -$k))15 (( load (+ 0 sym -var -$k))16 (( load (+ 0 sym -var -$c))17 (( const i32 sym -var -)18 (( const i32 sym -var -227)19 (( const i32 sym -var -423)20 (( const i32 sym -var -619)21 (( const i32 sym -var -815)22 (( const i32 sym -var -1011)23 (( const i32 sym -var -1207)24 (( const i32 sym -var -1403)25 (( const i32 sym -var -1599)

79

80 APPENDIX E. LEAKED OBSERVATIONS

26 (( const i32 sym -var -1795)27 (( const i32 sym -var -1991)28 (( store (+ 60 sym -var -$o))29 (( store (+ 56 sym -var -$o))30 (( store (+ 52 sym -var -$o))31 (( store (+ 48 sym -var -$o))32 (( store (+ 44 sym -var -$o))33 (( store (+ 40 sym -var -$o))34 (( store (+ 36 sym -var -$o))35 (( store (+ 32 sym -var -$o))36 (( store (+ 28 sym -var -$o))37 (( store (+ 24 sym -var -$o))38 (( store (+ 20 sym -var -$o))39 (( store (+ 16 sym -var -$o))40 (( store (+ 12 sym -var -$o))41 (( store (+ 8 sym -var -$o))42 (( store (+ 4 sym -var -$o))43 (( store (+ 0 sym -var -$o))44 ))))))))))))))))))))))))))))))))))))))))

)))

Right:

1 (( load (+ 12 sym -var -$c))2 (( load (+ 28 sym -var -$k))3 (( load (+ 24 sym -var -$k))4 (( load (+ 20 sym -var -$k))5 (( load (+ 16 sym -var -$k))6 (( load (+ 8 sym -var -$c))7 (( load (+ 12 sym -var -$p))8 (( load (+ 8 sym -var -$p))9 (( load (+ 4 sym -var -$p))10 (( load (+ 0 sym -var -$p))11 (( load (+ 4 sym -var -$c))12 (( load (+ 12 sym -var -$k))13 (( load (+ 8 sym -var -$k))14 (( load (+ 4 sym -var -$k))15 (( load (+ 0 sym -var -$k))16 (( load (+ 0 sym -var -$c))17 (( const i32 sym -var -32)

APPENDIX E. LEAKED OBSERVATIONS 81

18 (( const i32 sym -var -228)19 (( const i32 sym -var -424)20 (( const i32 sym -var -620)21 (( const i32 sym -var -816)22 (( const i32 sym -var -1012)23 (( const i32 sym -var -1208)24 (( const i32 sym -var -1404)25 (( const i32 sym -var -1600)26 (( const i32 sym -var -1796)27 (( const i32 sym -var -1992)28 (( store (+ 60 sym -var -$o))29 (( store (+ 56 sym -var -$o))30 (( store (+ 52 sym -var -$o))31 (( store (+ 48 sym -var -$o))32 (( store (+ 44 sym -var -$o))33 (( store (+ 40 sym -var -$o))34 (( store (+ 36 sym -var -$o))35 (( store (+ 32 sym -var -$o))36 (( store (+ 28 sym -var -$o))37 (( store (+ 24 sym -var -$o))38 (( store (+ 20 sym -var -$o))39 (( store (+ 16 sym -var -$o))40 (( store (+ 12 sym -var -$o))41 (( store (+ 8 sym -var -$o))42 (( store (+ 4 sym -var -$o))43 (( store (+ 0 sym -var -$o))44 ))))))))))))))))))))))))))))))))))))))))

)))

TRITA -EECS-EX-2020:638

www.kth.se

Date post:	04-Oct-2020
Category:	Documents
Upload:	others
View:	5 times
Download:	0 times

Relational Symbolic Execution in WebAssembly1471675/...DEGREE PROJECT IN COMPUTER SCIENCE AND...

Documents