-
Notifications
You must be signed in to change notification settings - Fork 15
Sandboxing loads and stores #13
Comments
You can implement it like as follows on 64-bit platforms. When you compile code, let's say that you have the start of the linear memory in some register In run time, when you instantiate a linear memory, you allocate 4GB(*) worth of virtual memory pages. You do that unconditionally (even if only 1 page was requested you still map all 4GBs). However, you mark as readable/writeable only the part that was explictly requested by the memory definition. The rest of this 4GB (if any) is marked as non-acccessible. When you jump to compiled code you pass the start of the memory to the register Then it is up to you to catch this trap. For POSIX like systems you should be able to install a signal handler before jumping to generated code and to save See:
(*) there is a catch. It is actually possible to specify address for more than 4GB, since |
What @pepyakin said :-). Also, wasmtime has support for allocating such memory regions, handling signals, and unwinding with A first step might be using wasmtime-environ to decode the Module as I sketched out here. Once that's in place, we might want to move lightbeam to live within the wasmtime repository. We'll probably need to make some changes to wasmtime to integrate it well, but we can do that. |
I propose the following plan:
For reference, the pointer to the array of linear memory records is here. To make it easy to access these fields, wasmtime-environ provides functions that return the offsets to these fields. Construct a Once we have the base address and the length, we can emit the code to do the bounds check if needed, and the access. It's simplest to start by reloading the base and length for each access, and then we can make it be clever about reusing the base and length in a register later, as we'll need to be careful about caching these values across a potential heap resize. There's admittedly a lot here, and a lot of this is new API surface area in Wasmtime, so please ask if there's anything that doesn't make sense here. |
This is the first JIT that I've worked on, so I don't know how one goes about same-process memory isolation without generating check-address-and-trap instructions. Obviously check-and-trap is viable, but I feel like it must be possible to jack into the OS's (and therefore, hardware's) memory protection mechanisms to get the same protections with better performance. I assume it works by calling into the operating system to set accessible memory regions before jumping into wasm code and then resetting the accessible regions afterwards or when calling into host functions, but how do you stop the wasm code from doing an
i32.store
onto the program counter (by using some method to guess the location of it) without also preventing it from writing to the stack?The text was updated successfully, but these errors were encountered: