{"id":20009870,"url":"https://github.com/plsyssec/ms-wasm","last_synced_at":"2025-03-02T01:43:48.676Z","repository":{"id":144629451,"uuid":"588742100","full_name":"PLSysSec/ms-wasm","owner":"PLSysSec","description":"MS-Wasm: Soundly Enforcing Memory-Safe Execution of Unsafe Code. Build and reproduce the results from the paper.","archived":false,"fork":false,"pushed_at":"2023-01-18T17:29:43.000Z","size":4,"stargazers_count":8,"open_issues_count":0,"forks_count":0,"subscribers_count":12,"default_branch":"main","last_synced_at":"2025-01-12T14:37:55.591Z","etag":null,"topics":[],"latest_commit_sha":null,"homepage":"https://doi.org/10.1145/3571208","language":null,"has_issues":true,"has_wiki":null,"has_pages":null,"mirror_url":null,"source_name":null,"license":null,"status":null,"scm":"git","pull_requests_enabled":true,"icon_url":"https://github.com/PLSysSec.png","metadata":{"files":{"readme":"README.md","changelog":null,"contributing":null,"funding":null,"license":null,"code_of_conduct":null,"threat_model":null,"audit":null,"citation":null,"codeowners":null,"security":null,"support":null,"governance":null,"roadmap":null,"authors":null,"dei":null,"publiccode":null,"codemeta":null}},"created_at":"2023-01-13T21:57:52.000Z","updated_at":"2024-11-29T19:55:12.000Z","dependencies_parsed_at":"2023-07-04T19:34:30.201Z","dependency_job_id":null,"html_url":"https://github.com/PLSysSec/ms-wasm","commit_stats":null,"previous_names":[],"tags_count":0,"template":false,"template_full_name":null,"repository_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/PLSysSec%2Fms-wasm","tags_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/PLSysSec%2Fms-wasm/tags","releases_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/PLSysSec%2Fms-wasm/releases","manifests_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/PLSysSec%2Fms-wasm/manifests","owner_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners/PLSysSec","download_url":"https://codeload.github.com/PLSysSec/ms-wasm/tar.gz/refs/heads/main","host":{"name":"GitHub","url":"https://github.com","kind":"github","repositories_count":241447522,"owners_count":19964314,"icon_url":"https://github.com/github.png","version":null,"created_at":"2022-05-30T11:31:42.601Z","updated_at":"2022-07-04T15:15:14.044Z","host_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub","repositories_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories","repository_names_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repository_names","owners_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners"}},"keywords":[],"created_at":"2024-11-13T07:17:21.091Z","updated_at":"2025-03-02T01:43:48.651Z","avatar_url":"https://github.com/PLSysSec.png","language":null,"funding_links":[],"categories":[],"sub_categories":[],"readme":"# MS-Wasm: Soundly Enforcing Memory-Safe Execution of Unsafe Code\n\nThis repository contains all the code necessary for building MS-\nWasm and reproducing the results presented in [our paper](https://doi.org/10.1145/3571208).\n\n## Abstract\nMost programs compiled to WebAssembly (Wasm) today are written in unsafe\nlanguages like C and C++. Unfortunately, memory-unsafe C code remains unsafe\nwhen compiled to Wasm—and attackers can exploit buffer overflows and use-\nafter-frees in Wasm almost as easily as they can on native platforms. Memory-\nSafe WebAssembly (MSWasm) proposes to extend Wasm with language-level memory-\nsafety abstractions to precisely address this problem. In this paper, we build\non the original MSWasm position paper to realize this vision. We give a precise\nand formal semantics of MSWasm, and prove that well-typed MSWasm programs\nare, by construction, robustly memory safe. To this end, we develop a novel,\nlanguage-independent memory-safety property based on colored memory locations\nand pointers. This property also lets us reason about the security guarantees\nof a formal C-to-MSWasm compiler—and prove that it always produces memory-safe\nprograms (and preserves the semantics of safe programs). We use these formal\nresults to then guide several implementations: Two compilers of MSWasm to native\ncode, and a C-to-MSWasm compiler (that extends Clang). Our MSWasm compilers\nsupport different enforcement mechanisms, allowing developers to make security-\nperformance trade-offs according to their needs. Our evaluation shows that\non the PolyBenchC suite, the overhead of enforcing memory safety in software\nranges from 22% (enforcing spatial safety alone) to 198% (enforcing full memory\nsafety), and 51.7% when using hardware memory capabilities for spatial safety\nand pointer integrity.\n\nMore importantly, MSWasm’s design makes it easy to swap between enforcement\nmechanisms; as fast (especially hardware-based) enforcement techniques become\navailable, MSWasm will be able to take advantage of these advances almost for\nfree.\n\n## Repositories\n\nEach name links to its Github repo.\n\n### Implementations\n\n- [`rWasm`](https://github.com/secure-foundations/rWasm/tree/mswasm): source\n  code for our AOT compiler from MSWasm bytecode. Consists of rWasm with\n  modifications to support compiling from MSWasm bytecode. This is available\n  on the `PATH` of the docker container: running `rWasm -w --ms-wasm\n  \u003cpath/to/mswasm/file\u003e` will create a folder named `generated`. The\n  `--ms-wasm-packed-tags`, `--ms-wasm-no-tags`, `--ms-wasm-baggy-bounds` flags\n  can optionally be added to change the runtime enforcement used. Run `rwasm -–help`\n  for more information and additional options. `cd`ing into the `generated` folder\n  and running `cargo run --release` will run the program. To compile to Cheri-C\n  instead, use the [`mswasm-cheri`](https://github.com/secure-foundations/rWasm/tree/mswasm-cheri)\n  branch and add the `--cheri` flag.\n\n- [`mswasm-graal`](https://github.com/PLSysSec/mswasm-graal): source code for\n  our JIT compiler from MSWasm bytecode. Consists of GraalVM with modifications\n  to support MSWasm Bytecode. `mswasm-graal` is available on the `PATH` of\n  the docker container: running `mswasm-graal –Builtins=wasi_snapshot_preview1\n  \u003cpath/to/mswasm/file\u003e` will run the file. There is also a version of\n  Graal’s implementation of vanilla Wasm on the path - running `wasm-graal\n  --Builtins=wasi_snapshot_preview1 \u003cpath/to/wasm/file\u003e` will run the Wasm\n  program.\n\n### Compiler\n\n- [`mswasm-llvm`](https://github.com/PLSysSec/mswasm-llvm.git): source code\n  for our compiler from C to MSWasm bytecode. Consists of a fork of LLVM\n  (specifically, the CHERI fork of LLVM) with modifications to produce MSWasm\n  bytecode. Running `/home/mswasm-llvm/llvm/build/bin/clang –target=wasm32-wasi\n  --sysroot=”/home/mswasm-wasi-libc/sysroot” \u003cpath/to/c/file\u003e` will generate\n  an MSWasm program from a basic C program. Due to current limitations of the\n  MSWasm prototypes, clang does not correctly compile arbitrary programs. In\n  particular, expect errors on most programs that use `stdout`.\n\n### Supporting Tools\n\n- [`mswasm-wasi-libc`](https://github.com/PLSysSec/mswasm-wasi-libc): source\n  code for supporting compilation of C executables to MSWasm bytecode. Consists\n  of WASI-libc with modifications to support MSWasm bytecode.\n\n- [`mswasm-polybench`](https://github.com/PLSysSec/mswasm-polybench): PolybenchC\n  benchmarks, compiled to native x86-64 code, Wasm bytecode, and MSWasm\n  bytecode; along with scripts to perform benchmarking. Inside of the benchmark-\n  binaries folders, there are `.mswasm` MS-WebAssembly binary files to be run\n  by `rWasm` and `mswasm-graal` `.mswat` MS-WebAssembly text files to be read by\n  humans `.native` binaries to run as native C code `.wasm` WebAssembly binaries\n  to be run by `rWasm` and `wasm-graal` `.wat` WebAssembly text files to be read\n  by humans.\n\n- [`mswasm-wabt`](https://github.com/PLSysSec/mswasm-wabt): source code for\n  `mswasm2wat`, a utility for converting MSWasm files into a readable text\n  format. Consists of a fork of [WABT](https://github.com/WebAssembly/wabt)\n  partially modified to work on MSWasm bytecode. `mswasm2wat` is available on\n  the `PATH` and takes an MSWasm binary file as input. For more information\n  Wasm text format, see [this guide](https://developer.mozilla.org/en-US/docs/\n  WebAssembly/Understanding_the_text_format).\n\n## Reproducing Evaluation Results\n\n### Install\n\n#### Docker Container\nWe provide a Docker container to create an environment to run these benchmarks at\n[ghcr.io/plsyssec/mswasm](https://ghcr.io/plsyssec/mswasm).  To install, install\n[Docker](https://www.docker.com) and run\n\n```shell\ndocker pull ghcr.io/plsyssec/mswasm:latest\n```\n\nThis will download the container. The container is around 80GB. Once the\ncontainer is downloaded, you can run it with commands such as\n\n```shell\ndocker run -it mswasm:latest\n```\n\nYou may also use the Docker desktop interface if desired.\n\n#### Dockerfile\nWe provide a [Dockerfile](Dockerfile) to create an environment to run these\nbenchmarks. To install, install [Docker](https://www.docker.com/), and in the\nsame directory as the Dockerfile, run\n\n```shell\ndocker build -t mswasm .\n```\n\nThis will build the container. This will take a reasonable amount of time\n(around 45 minutes on our host machine) and require internet for cloning git\nrepositories. This will take more than 32GB of RAM due to compilation, and the\nfinal image will be around 80GB. Once the container is built, you can run it\nwith commands such as\n\n```shell\ndocker run -it mswasm:latest\n```\nYou may also use the Docker desktop interface if desired.\n\n### Container Organization\n\n### Running Benchmarks\nTo run the benchmark suite from the paper, use the original benchify.toml file\nwith uncommented warmup, min_run and max_run values. The original file can be\nfound in the `mswasm-polybench` repo. Running the entire benchmark suite will\ntake a substantial amount of time. It would be advised to lower the min and max\nruns.\n\nIt can be run with the same instructions as before: `cd mswasm-polybench`\n`benchify benchify.toml`. Output will be generated on stdout and in the\nbenchify-results folder.\n\n#### Choosing Tests\n\nTo choose which tests to run, you can modify the `benchify.toml` file.\nThe `min_runs` and `max_runs` numbers will determine the number of times\na benchmark will be run. Lowering these values to 3 will provide a quicker\nbenchmark run, but the results will have more noise.\n\nYou can comment tests out by removing or commenting them out in `benchify.toml`.\nFor instance, if I only wanted to run the `2mm` benchmark, my `benchify.toml` would\nlook like\n\n```\n    [[tests]]\n    name = \"2mm\"\n    tag = \"wasi\"\n    file = \"benchmark-binaries/2mm.mswasm\"\n    stdout_is_timing = true\n\n  # [[tests]]\n  # name = \"3mm\"\n  # tag = \"wasi\"\n  # file = \"benchmark-binaries/3mm.mswasm\"\n  # stdout_is_timing = true\n  #\n  # [[tests]]\n  # name = \"adi\"\n  # tag = \"wasi\"\n  # file = \"benchmark-binaries/adi.mswasm\"\n  # stdout_is_timing = true\n  #\n  # [[tests]]\n  # name = \"atax\"\n  # tag = \"wasi\"\n  # file = \"benchmark-binaries/atax.mswasm\"\n  # stdout_is_timing = true\n  ```\n  \n#### Generating Graphs\n\nTo generate the graphs used in the paper, you can use the\n[`generate-graphs.py`](generate-graphs.py) script. If you wish to run\nthe script from the container, run `git pull` from the `mswasm-polybench` repo\nto pull the script, and then run `apt-get update \u0026\u0026 apt-get install\npython3-matplotlib python3-pandas python3-seaborn` to install needed\ndependencies. The script can then be run as\n\n```shell\npython3 \u003cpath to generate-graphs.py\u003e \u003cpath to benchify csv data in benchify-results\u003e\n```\n\nThe script will generate 5 graphs as pdfs in the current working directory.\nYou can extract these graphs from the container with `docker cp`, such as\n\n```shell\ndocker container ls # find the name of your container\ndocker cp \u003ccontainer name\u003e:\u003cpath to pdf\u003e \u003cpath on local machine to copy to\u003e\n```\n\nAlternatively, the python script only requires the benchify csv data, so\nit does not need to be run on the container. `docker cp` can be used to\nretrieve the benchify csv data, then the python script can be run on\na local machine that has python3 and matplotlib, pandas, and seaborn\ninstalled.\n","project_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fplsyssec%2Fms-wasm","html_url":"https://awesome.ecosyste.ms/projects/github.com%2Fplsyssec%2Fms-wasm","lists_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fplsyssec%2Fms-wasm/lists"}