topic.wasmjs.group.bib

@comment{{This file has been generated by bib2bib 1.99}}
@comment{{Command line: bibtex2html-1.99-with-magiclink/bib2bib -c topic:"wasmjs" -ob topic.wasmjs.group.bib groupbib.bib}}
@inproceedings{DBLP:conf/pldi/WattPPBDFPG20,
  author = {Conrad Watt and
               Christopher Pulte and
               Anton Podkopaev and
               Guillaume Barbier and
               Stephen Dolan and
               Shaked Flur and
               Jean Pichon{-}Pharabod and
               Shu{-}yu Guo},
  opteditor = {Alastair F. Donaldson and               Emina Torlak},
  title = {Repairing and mechanising the JavaScript relaxed memory model},
  conf = {PLDI 2020},
  booktitle = {Proceedings of the 41st {ACM} {SIGPLAN} International Conference on
               Programming Language Design and Implementation},
  pages = {346--361},
  publisher = {{ACM}},
  year = {2020},
  url = {https://doi.org/10.1145/3385412.3385973},
  doi = {10.1145/3385412.3385973},
  timestamp = {Thu, 21 Jan 2021 17:36:44 +0100},
  biburl = {https://dblp.org/rec/conf/pldi/WattPPBDFPG20.bib},
  bibsource = {dblp computer science bibliography, https://dblp.org},
  abstract = {Modern JavaScript includes the SharedArrayBuffer feature, which provides access to true shared memory concurrency. SharedArrayBuffers are simple linear buffers of bytes, and the JavaScript specification defines an axiomatic relaxed memory model to describe their behaviour. While this model is heavily based on the C/C++11 model, it diverges in some key areas. JavaScript chooses to give a well-defined semantics to data-races, unlike the "undefined behaviour" of C/C++11. Moreover, the JavaScript model is mixed-size. This means that its accesses are not to discrete locations, but to (possibly overlapping) ranges of bytes.

We show that the model, in violation of the design intention, does not support a compilation scheme to ARMv8 which is used in practice. We propose a correction, which also incorporates a previously proposed fix for a failure of the model to provide Sequential Consistency of Data-Race-Free programs (SC-DRF), an important correctness condition. We use model checking, in Alloy, to generate small counter-examples for these deficiencies, and investigate our correction. To accomplish this, we also develop a mixed-size extension to the existing ARMv8 axiomatic model.

Guided by our Alloy experimentation, we mechanise (in Coq) the JavaScript model (corrected and uncorrected), our ARMv8 model, and, for the corrected JavaScript model, a "model-internal" SC-DRF proof and a compilation scheme correctness proof to ARMv8. In addition, we investigate a non-mixed-size subset of the corrected JavaScript model, and give proofs of compilation correctness for this subset to x86-TSO, Power, RISC-V, ARMv7, and (again) ARMv8, via the Intermediate Memory Model (IMM).

As a result of our work, the JavaScript standards body (ECMA TC39) will include fixes for both issues in an upcoming edition of the specification. },
  elver = {true},
  topic = {wasmjs}
}
@article{DBLP:journals/pacmpl/WattRP19,
  author = {Conrad Watt and
               Andreas Rossberg and
               Jean Pichon{-}Pharabod},
  title = {Weakening WebAssembly},
  journal = {Proc. {ACM} Program. Lang.},
  volume = {3},
  number = {{OOPSLA}},
  pages = {133:1--133:28},
  year = {2019},
  url = {https://doi.org/10.1145/3360559},
  doi = {10.1145/3360559},
  timestamp = {Wed, 16 Mar 2022 23:49:28 +0100},
  biburl = {https://dblp.org/rec/journals/pacmpl/WattRP19.bib},
  bibsource = {dblp computer science bibliography, https://dblp.org},
  topic = {wasmjs}
}
@article{DBLP:journals/pacmpl/WattRPCS19,
  author = {Conrad Watt and
               John Renner and
               Natalie Popescu and
               Sunjay Cauligi and
               Deian Stefan},
  title = {CT-wasm: type-driven secure cryptography for the web ecosystem},
  journal = {Proc. {ACM} Program. Lang.},
  volume = {3},
  number = {{POPL}},
  pages = {77:1--77:29},
  year = {2019},
  url = {https://doi.org/10.1145/3290390},
  doi = {10.1145/3290390},
  timestamp = {Wed, 16 Mar 2022 23:49:28 +0100},
  biburl = {https://dblp.org/rec/journals/pacmpl/WattRPCS19.bib},
  bibsource = {dblp computer science bibliography, https://dblp.org},
  topic = {wasmjs}
}
@inproceedings{DBLP:conf/ecoop/WattMKG19,
  author = {Conrad Watt and
               Petar Maksimovic and
               Neelakantan R. Krishnaswami and
               Philippa Gardner},
  opteditor = {Alastair F. Donaldson},
  title = {A Program Logic for First-Order Encapsulated WebAssembly},
  conf = {ECOOP 2019},
  booktitle = {33rd European Conference on Object-Oriented Programming},
  series = {LIPIcs},
  volume = {134},
  pages = {9:1--9:30},
  publisher = {Schloss Dagstuhl - Leibniz-Zentrum f{\"{u}}r Informatik},
  year = {2019},
  url = {https://doi.org/10.4230/LIPIcs.ECOOP.2019.9},
  doi = {10.4230/LIPIcs.ECOOP.2019.9},
  timestamp = {Sun, 25 Oct 2020 22:50:36 +0100},
  biburl = {https://dblp.org/rec/conf/ecoop/WattMKG19.bib},
  bibsource = {dblp computer science bibliography, https://dblp.org},
  topic = {wasmjs}
}
@inproceedings{DBLP:conf/cpp/Watt18,
  author = {Conrad Watt},
  opteditor = {June Andronick and               Amy P. Felty},
  title = {Mechanising and verifying the WebAssembly specification},
  conf = {CPP 2018},
  booktitle = {Proceedings of the 7th {ACM} {SIGPLAN} International Conference on
               Certified Programs and Proofs},
  pages = {53--65},
  publisher = {{ACM}},
  year = {2018},
  url = {https://doi.org/10.1145/3167082},
  doi = {10.1145/3167082},
  timestamp = {Wed, 21 Nov 2018 12:44:26 +0100},
  biburl = {https://dblp.org/rec/conf/cpp/Watt18.bib},
  bibsource = {dblp computer science bibliography, https://dblp.org},
  topic = {wasmjs}
}
@inproceedings{DBLP:conf/fm/WattRPBG21,
  author = {Conrad Watt and
                  Xiaojia Rao and
                  Jean Pichon{-}Pharabod and
                  Martin Bodin and
                  Philippa Gardner},
  opteditor = {Marieke Huisman and
                  Corina S. Pasareanu and
                  Naijun Zhan},
  title = {Two Mechanisations of WebAssembly 1.0},
  conf = {FM 2021},
  booktitle = {Formal Methods - 24th International Symposium, {FM} 2021, Virtual
                  Event, November 20-26, 2021, Proceedings},
  series = {Lecture Notes in Computer Science},
  volume = {13047},
  pages = {61--79},
  publisher = {Springer},
  year = {2021},
  url = {https://doi.org/10.1007/978-3-030-90870-6\_4},
  doi = {10.1007/978-3-030-90870-6\_4},
  timestamp = {Tue, 21 Mar 2023 20:56:17 +0100},
  biburl = {https://dblp.org/rec/conf/fm/WattRPBG21.bib},
  bibsource = {dblp computer science bibliography, https://dblp.org},
  elver = {true},
  abstract = {WebAssembly (Wasm) is a new bytecode language supported by all major Web browsers, designed primarily to be an efficient compilation target for low-level languages such as C/C++ and Rust. It is unusual in that it is officially specified through a formal semantics. An initial draft specification was published in 2017 with an associated mechanised specification in Isabelle/HOL published by Watt that found bugs in the original specification, fixed before its publication. The first official W3C standard, WebAssembly 1.0, was published in 2019. Building on Watt’s original mechanisation, we introduce two mechanised specifications of the WebAssembly 1.0 semantics, written in different theorem provers: WasmCert-Isabelle and WasmCert-Coq. Wasm’s compact design and official formal semantics enable our mechanisations to be particularly complete and close to the published language standard. We present a high-level description of the language’s updated type soundness result, referencing both mechanisations. We also describe the current state of the mechanisation of language features not previously supported: WasmCert-Isabelle includes a verified executable definition of the instantiation phase as part of an executable verified interpreter; WasmCert-Coq includes executable parsing and numeric definitions as on-going work towards a more ambitious end-to-end verified interpreter which does not require an OCaml harness like WasmCert-Isabelle. },
  topic = {wasmjs}
}
@article{DBLP:journals/pacmpl/KolosickNJWLGJS22,
  author = {Matthew Kolosick and
                  Shravan Narayan and
                  Evan Johnson and
                  Conrad Watt and
                  Michael LeMay and
                  Deepak Garg and
                  Ranjit Jhala and
                  Deian Stefan},
  title = {Isolation without taxation: near-zero-cost transitions for WebAssembly
                  and {SFI}},
  journal = {Proc. {ACM} Program. Lang.},
  conf = {POPL},
  volume = {6},
  number = {{POPL}},
  pages = {1--30},
  year = {2022},
  month = jan,
  url = {https://doi.org/10.1145/3498688},
  doi = {10.1145/3498688},
  pdf = {https://dl.acm.org/doi/pdf/10.1145/3498688},
  timestamp = {Thu, 16 Mar 2023 10:47:39 +0100},
  biburl = {https://dblp.org/rec/journals/pacmpl/KolosickNJWLGJS22.bib},
  bibsource = {dblp computer science bibliography, https://dblp.org},
  abstract = {Software sandboxing or software-based fault isolation (SFI) is a lightweight approach to building secure systems out of untrusted components. Mozilla, for example, uses SFI to harden the Firefox browser by sandboxing third-party libraries, and companies like Fastly and Cloudflare use SFI to safely co-locate untrusted tenants on their edge clouds. While there have been significant efforts to optimize and verify SFI enforcement, context switching in SFI systems remains largely unexplored: almost all SFI systems use heavyweight transitions that are not only error-prone but incur significant performance overhead from saving, clearing, and restoring registers when context switching. We identify a set of zero-cost conditions that characterize when sandboxed code has sufficient structured to guarantee security via lightweight zero-cost transitions (simple function calls). We modify the Lucet Wasm compiler and its runtime to use zero-cost transitions, eliminating the undue performance tax on systems that rely on Lucet for sandboxing (e.g., we speed up image and font rendering in Firefox by up to 29.7\% and 10\% respectively). To remove the Lucet compiler and its correct implementation of the Wasm specification from the trusted computing base, we (1) develop a static binary verifier, VeriZero, which (in seconds) checks that binaries produced by Lucet satisfy our zero-cost conditions, and (2) prove the soundness of VeriZero by developing a logical relation that captures when a compiled Wasm function is semantically well-behaved with respect to our zero-cost conditions. Finally, we show that our model is useful beyond Wasm by describing a new, purpose-built SFI system, SegmentZero32, that uses x86 segmentation and LLVM with mostly off-the-shelf passes to enforce our zero-cost conditions; our prototype performs on-par with the state-of-the-art Native Client SFI system.},
  topic = {wasmjs}
}
@phdthesis{watt_2021,
  title = {Mechanising and evolving the formal semantics of WebAssembly: the Web's new low-level language},
  school = {University of Cambridge},
  url = {https://www.repository.cam.ac.uk/handle/1810/329032},
  doi = {10.17863/CAM.76476},
  publisher = {Apollo -- University of Cambridge Repository},
  author = {Watt,    Conrad},
  year = {2021},
  keywords = {WebAssembly, mechanisation, Isabelle/HOL, virtual machine, programming language semantics, WasmCert},
  note = {EAPLS Best Dissertation Award 2021, and Honorable Mention for the 2022 ACM Doctoral Dissertation Award},
  abstract = {WebAssembly is the first new programming language to be supported natively by all major Web browsers since JavaScript. It is designed to be a natural low-level compilation target for languages such as C, C++, and Rust, enabling programs written in these languages to be compiled and executed efficiently on the Web. WebAssembly’s specification is managed by the W3C WebAssembly Working Group (made up of representatives from a number of major tech companies). Uniquely, the language is specified by way of a full pen-and-paper formal semantics.

This thesis describes a number of ways in which I have both helped to shape the specification of WebAssembly, and built upon it. By mechanising the WebAssembly formal semantics in Isabelle/HOL while it was being drafted, I discovered a number of errors in the specification, drove the adoption of official corrections, and provided the first type soundness proof for the corrected language. This thesis also details a verified type checker and interpreter, and a security type system extension for cryptography primitives, all of which have been mechanised as extensions of my initial WebAssembly mechanisation.

A major component of the thesis is my work on the specification of shared memory concurrency in Web languages: correcting and verifying properties of JavaScript’s existing relaxed memory model, and defining the WebAssembly-specific extensions to the corrected model which have been adopted as the basis of WebAssembly’s official threads specification. A number of deficiencies in the original JavaScript model are detailed. Some errors have been corrected, with the verified fixes officially adopted into subsequent editions of the language specification. However one discovered deficiency is fundamental to the model, an instance of the well-known "thin-air problem".

My work demonstrates the value of formalisation and mechanisation in industrial programming language design, not only in discovering and correcting specification errors, but also in building confidence both in the correctness of the language’s design and in the design of proposed extensions.
},
  topic = {wasmjs}
}
@article{DBLP:journals/pacmpl/MichaelGBJDDWPPVS23,
  author = {Alexandra E. Michael and
                  Anitha Gollamudi and
                  Jay Bosamiya and
                  Evan Johnson and
                  Aidan Denlinger and
                  Craig Disselkoen and
                  Conrad Watt and
                  Bryan Parno and
                  Marco Patrignani and
                  Marco Vassena and
                  Deian Stefan},
  title = {MSWasm: Soundly Enforcing Memory-Safe Execution of Unsafe Code},
  journal = {Proc. {ACM} Program. Lang.},
  conf = {POPL 2023},
  volume = {7},
  number = {{POPL}},
  pages = {425--454},
  year = {2023},
  month = jan,
  url = {https://doi.org/10.1145/3571208},
  doi = {10.1145/3571208},
  pdf = {https://dl.acm.org/doi/pdf/10.1145/3571208},
  timestamp = {Thu, 16 Mar 2023 10:47:39 +0100},
  biburl = {https://dblp.org/rec/journals/pacmpl/MichaelGBJDDWPPVS23.bib},
  bibsource = {dblp computer science bibliography, https://dblp.org},
  abstract = {Most programs compiled to WebAssembly (Wasm) today are written in unsafe languages like C and C++. Unfortunately, memory-unsafe C code remains unsafe when compiled to Wasm---and attackers can exploit buffer overflows and use-after-frees in Wasm almost as easily as they can on native platforms. Memory- Safe WebAssembly (MSWasm) proposes to extend Wasm with language-level memory-safety abstractions to precisely address this problem. In this paper, we build on the original MSWasm position paper to realize this vision. We give a precise and formal semantics of MSWasm, and prove that well-typed MSWasm programs are, by construction, robustly memory safe. To this end, we develop a novel, language-independent memory-safety property based on colored memory locations and pointers. This property also lets us reason about the security guarantees of a formal C-to-MSWasm compiler---and prove that it always produces memory-safe programs (and preserves the semantics of safe programs). We use these formal results to then guide several implementations: Two compilers of MSWasm to native code, and a C-to-MSWasm compiler (that extends Clang). Our MSWasm compilers support different enforcement mechanisms, allowing developers to make security-performance trade-offs according to their needs. Our evaluation shows that on the PolyBenchC suite, the overhead of enforcing memory safety in software ranges from 22\% (enforcing spatial safety alone) to 198\% (enforcing full memory safety), and 51.7\% when using hardware memory capabilities for spatial safety and pointer integrity.

More importantly, MSWasm’s design makes it easy to swap between enforcement mechanisms; as fast (especially hardware-based) enforcement techniques become available, MSWasm will be able to take advantage of these advances almost for free.},
  topic = {wasmjs}
}
@article{10.1145/3591224,
  author = {Watt, Conrad and Trela, Maja and Lammich, Peter and M\"{a}rkl, Florian},
  title = {WasmRef-Isabelle: A Verified Monadic Interpreter and Industrial Fuzzing Oracle for WebAssembly},
  conf = {PLDI 2023},
  year = {2023},
  issue_date = {June 2023},
  publisher = {Association for Computing Machinery},
  address = {New York, NY, USA},
  volume = {7},
  number = {PLDI},
  url = {https://doi.org/10.1145/3591224},
  doi = {10.1145/3591224},
  pdf = {https://dl.acm.org/doi/pdf/10.1145/3591224},
  abstract = {We present WasmRef-Isabelle, a monadic interpreter for WebAssembly written in Isabelle/HOL and proven correct with respect to the WasmCert-Isabelle mechanisation of WebAssembly. WasmRef-Isabelle has been adopted and deployed as a fuzzing oracle in the continuous integration infrastructure of Wasmtime, a widely used WebAssembly implementation. Previous efforts to fuzz Wasmtime against WebAssembly's official OCaml reference interpreter were abandoned by Wasmtime's developers after the reference interpreter exhibited unacceptable performance characteristics, which its maintainers decided not to fix in order to preserve the interpreter's close definitional correspondence with the official specification. With WasmRef-Isabelle, we achieve the best of both worlds - an interpreter fast enough to be useable as a fuzzing oracle that also maintains a close correspondence with the specification through a mechanised proof of correctness. We verify the correctness of WasmRef-Isabelle through a two-step refinement proof in Isabelle/HOL. We demonstrate that WasmRef-Isabelle significantly outperforms the official reference interpreter, has performance comparable to a Rust debug build of the industry WebAssembly interpreter Wasmi, and competes with unverified oracles on fuzzing throughput when deployed in Wasmtime's fuzzing infrastructure. We also present several new extensions to WasmCert-Isabelle which enhance WasmRef-Isabelle's utility as a fuzzing oracle: we add support for a number of upcoming WebAssembly features, and fully mechanise the numeric semantics of WebAssembly's integer operations.},
  journal = {Proc. ACM Program. Lang.},
  month = jun,
  articleno = {110},
  numpages = {24},
  keywords = {theorem proving, virtual machine, refinement, WasmCert},
  topic = {wasmjs}
}
@article{10.1145/3591265,
  author = {Rao, Xiaojia and Georges, A\"{\i}na Linn and Legoupil, Maxime and Watt, Conrad and Pichon-Pharabod, Jean and Gardner, Philippa and Birkedal, Lars},
  title = {Iris-Wasm: Robust and Modular Verification of WebAssembly Programs},
  year = {2023},
  conf = {PLDI 2023},
  issue_date = {June 2023},
  publisher = {Association for Computing Machinery},
  address = {New York, NY, USA},
  volume = {7},
  number = {PLDI},
  url = {https://doi.org/10.1145/3591265},
  doi = {10.1145/3591265},
  pdf = {https://dl.acm.org/doi/pdf/10.1145/3591265},
  abstract = {WebAssembly makes it possible to run C/C++ applications on the web with near-native performance. A WebAssembly program is expressed as a collection of higher-order ML-like modules, which are composed together through a system of explicit imports and exports using a host language, enabling a form of higher- order modular programming. We present Iris-Wasm, a mechanized higher-order separation logic building on a specification of Wasm 1.0 mechanized in Coq and the Iris framework. Using Iris-Wasm, we are able to specify and verify individual modules separately, and then compose them modularly in a simple host language featuring the core operations of the WebAssembly JavaScript Interface. Building on Iris-Wasm, we develop a logical relation that enforces robust safety: unknown, adversarial code can only affect other modules through the functions that they explicitly export. Together, the program logic and the logical relation allow us to formally verify functional correctness of WebAssembly programs, even when they invoke and are invoked by unknown code, thereby demonstrating that WebAssembly enforces strong isolation between modules.},
  journal = {Proc. ACM Program. Lang.},
  month = jun,
  articleno = {151},
  numpages = {25},
  keywords = {higher-order logic, formal verification, WebAssembly, separation logic},
  topic = {wasmjs}
}