wasm-micro-runtime icon indicating copy to clipboard operation
wasm-micro-runtime copied to clipboard

Any approach to map memory within a Wasm instance to some specific memory region of its host?

Open MrHate opened this issue 2 years ago • 4 comments

Although it might a bit conflict with the security design of Wasm, is there any approach to map a memory region within a Wasm instance to a specific memory region of its host? Or could I have a Wasm instance access some memory region of its host? My scenario involves an application that keeps exchanging data in large blocks, and a platform-specific host design which always processes such data at a fixed address region (e.g., an external device mapped to certain address). Either with or without wasm_runtime_module_malloc, I found myself unavoidably copying these blocks in and out each time. Is there something like mmap between the host and a Wasm instance? Thx.

MrHate avatar Dec 06 '23 10:12 MrHate

Hope those two are helpful:

  • https://bytecodealliance.github.io/wamr.dev/blog/the-wasm-host-sharing-data-basics/
  • https://bytecodealliance.github.io/wamr.dev/blog/the-wasm-host-sharing-data-challenges/

lum1n0us avatar Dec 07 '23 00:12 lum1n0us

Hope those two are helpful:

* https://bytecodealliance.github.io/wamr.dev/blog/the-wasm-host-sharing-data-basics/

* https://bytecodealliance.github.io/wamr.dev/blog/the-wasm-host-sharing-data-challenges/

Thank you very much for your helpful information!

This issue is still difficult to solve: performance and security cannot be balanced at the same time.

I guess doing something against the security design might be the only way?

MrHate avatar Dec 07 '23 09:12 MrHate

Wasm applications are supposed to run in sandboxes. So, in most cases, copying is a necessary step. But, decreasing copying times are full of hope.

lum1n0us avatar Dec 10 '23 23:12 lum1n0us

I made a simple POC working in a less risky way:

Sample:

uint32_t app_buf = 0;
char *dummy_buf = NULL, *p = NULL;
char hello_txt[] = "Hello mremap.";

app_buf = wasm_runtime_module_malloc(minst, DUMMY_BUF_SIZE, (void **)&p);
if (!app_buf) {
  printf("Failed module malloc.\n");
  goto cleanup;
}

dummy_buf = (char*)wasm_runtime_malloc(DUMMY_BUF_SIZE);
if (!dummy_buf) {
  printf("Failed malloc.\n");
 goto cleanup;
}

memset(dummy_buf, '*', DUMMY_BUF_SIZE);
memcpy(dummy_buf, hello_txt, sizeof(hello_txt));

if (!wasm_runtime_mremap(dummy_buf, app_buf, minst, DUMMY_BUF_SIZE)) {
  printf("Failed mremap.\n");
  goto cleanup;
}

//  void print_mem(u32 addr_offset, u32 size)
wapp_argv[0] = app_buf;
wapp_argv[1] = DUMMY_BUF_SIZE;
if (!wasm_runtime_call_wasm(exec_env, func, sizeof(wapp_argv)/sizeof(uint32_t), wapp_argv)) {
  printf("Failed calling func [%s]: %s\n",
         WAPP_ENTRY_FUNC,
         wasm_runtime_get_exception(module_inst));
  goto cleanup;
}

However, introducing an extra func call to each time accessing memory entails overhead in another way.

MrHate avatar Dec 11 '23 01:12 MrHate