Skip to content
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

Closed
loganek opened this issue Apr 12, 2024 · 5 comments
Closed

Optional memory sandboxing #3313

loganek opened this issue Apr 12, 2024 · 5 comments
Labels
new feature New feature request

Comments

@loganek
Copy link
Collaborator

loganek commented Apr 12, 2024

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.

@lum1n0us
Copy link
Collaborator

would u mind hinting us by some brief description?

@no1wudi
Copy link
Collaborator

no1wudi commented Apr 16, 2024

For this case, how about enable WAMR_CONFIGUABLE_BOUNDS_CHECKS and pass --disable-bounds-checks to iwasm ?

@wenyongh wenyongh added the new feature New feature request label Apr 17, 2024
@loganek
Copy link
Collaborator Author

loganek commented Apr 17, 2024

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.

@no1wudi
Copy link
Collaborator

no1wudi commented Apr 17, 2024

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 addr_native_to_app and addr_app_to_native during passing native address across wasm side and native side even it's not in the wasm linear memory.

@loganek
Copy link
Collaborator Author

loganek commented Apr 17, 2024

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.

@loganek loganek closed this as completed Apr 17, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
new feature New feature request
Projects
None yet
Development

No branches or pull requests

4 participants