Comments (3)
To completely sandbox the client, I guess it would be necessary to wrap any exported host functions, mapping client to host pointers, and write custom memory management routines.
That's correct. Here is some more detailed background:
There are two different top level programs (wac and wace) that setup memory/interfaces differently.
wac sets things up like a normal WebAssembly (WA) in a JavaScript context. If the WA code needs hope memory, then the host needs to alloc that memory and pass it in as an import. The WA code itself then needs to implement memory management. If you want to call imported functions, then those external functions will need to be aware of the memory space of the WA code and agree on the memory layout/management with the WA code. WA code running in wac has bounds checked memory reads/writes so it won't be able to access memory outside the imported memory (don't count on it for security, there are almost certainly ways around it). This means that any pointers (even strings) passed from the host environment into the WA code will not be accessible unless the host-side has mechanisms to allocate memory from the WA memory and then translate every pointer into the offset into the WA memory for every call into the WA code.
However, wac isn't really designed to run C code that was compiled to WebAssembly. That's where wace comes in. wace is designed to run C code compiled by emscripten (specifically `emcc -O2 -s WASM=1 -s SIDE_MODULE=1 -s LEGALIZE_JS_FFI=0). wace allocates memory for the WA code, but instead of passing that address in the memory import, it sets memory to point to 0 and sets memoryBase to point to the WA owned memory. This means that the WA code can use host memory pointers without translation. This means that normal C code (even code that calls back out to host functions) can be compiled with emscripten and run under wace. You can call host malloc and then use the memory, you can call host functions using pointer into host or WA memory, etc. The downside of course is that WA code running under wace is completely unsandboxed. Whatever the original C code could do, the WA compiled code can also do when run in wace.
So if you are wanting to sandbox code that is intended to run under WebAssembly (as opposed to arbitrary C code compiled to WebAssembly), then you would probably want to target wac. As you noted, you will have to do some sort of WA/host pointer translation to give WA access to the host. And if you are wanting to do this for security reasons, you probably will want to do a fairly in depth audit and testing (maybe with code fuzzing) to give confidence. The goal of wac/wace is to be a minimal C interpreter for WebAssembly with good host interop (i.e. security is not a focus/goal). However, that being said, I would be happy to take pull requests that don't balloon the core implementation. I.e. if you have a new front-end driver (sibling to wac/wace) to do what you want need plus some patches to the core to support it, I would be happy to consider merging it.
from wac.
Thank you for the detailed explanation - things are starting to make more sense to me now.
Since emscripten appears to be the easiest way to build wasm code, I've looked primarily into wace which exports the relevant stuff. However, it seems like wac will be more relevant for me.
My goal is to run WebAssembly as sandboxed as possible, without caring if it was compiled from C, Rust, or written by hand. Ideally, the front end would only expose a generic interface through syscalls - I think this is also where emscripten is heading.
For now, I guess, my best strategy will be to start with wac and implement the interface required by emscripten builds. Security is only a minor concern as this is a hobby project and there is only so much spare time :)
from wac.
In addition to the exports in #3 I'm going to do some more profound changes to the core to support freeing modules, not killing the main process on errors, and maybe running multiple WebAssembly instances.
I realize that these may not fit into the scope of wac or may cause unacceptable bloat so I'll create separate pull requests for these features and you can decide if you want them. Otherwise they'll live in my fork.
from wac.
Related Issues (15)
- -Wformat error HOT 4
- Use wast2json instead for generating tests? HOT 2
- Any plans to allow x64 (amd64) builds? HOT 6
- performance?
- Multiple heap-buffer-overflow vulnerabilities in interpret HOT 7
- Multiple heap-buffer-overflow in load_module HOT 1
- heap-buffer-overflow in setup_call
- DoS in wace
- cannot pull kanaka/emscripten from docker hub HOT 1
- Arm support? HOT 5
- wac crashes
- segmentation fault when running clang built wasm HOT 2
- examples cannot stat wasm files HOT 7
- Windows build download link
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from wac.