-
Notifications
You must be signed in to change notification settings - Fork 576
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Optional memory sandboxing #3313
Comments
would u mind hinting us by some brief description? |
For this case, how about enable WAMR_CONFIGUABLE_BOUNDS_CHECKS and pass --disable-bounds-checks to iwasm ? |
yes, I think that'd work. I'll need to do a few more experiments, but briefly having a look, that seems like exactly what I need. |
Please call |
Yes, those two functions will be needed to do the conversion as all the memory opcodes do the reverse thing; currently working with @TianlongLiang on memory64 so that approach will be feasible for 64bit platforms. I'm resolving the issue for now as there's a solution for my problem; I'll probably make separate PRs if I uncover any edge cases that aren't currently being implemented. |
This was already discussed a while ago with some of the folks from Intel, but sharing the idea here as well for visibility and comments.
Feature
For our use case the memory sandboxing is not needed as we control the entire software stack on the device. We'd like WASM code to access the entire address space, and not just the linear memory, so we can easily access the memory that's been allocated (either statically on the heap, or dynamically) by other, non-wasm components.
The feature will be guarded by a compilation flag and will be disabled by default.
Implementation
We'll provide a PR for that soon.
Alternatives
We considered alternative where other (non-wasm) components running as part of the process will use wasm memory. However, we'll require over a hundred megabytes of continuous virtual memory, and such a big continuous allocation or memory mapping will fail on some of the devices we support.
The text was updated successfully, but these errors were encountered: