Memory Resetting After Each Execution

[fridaymore]

We have a use case where we want to reset memory (e.g. memset 0) after each execution of a WASM module. The host platform is Linux. The WASM code is meant to be stateless and would be provided by a client that we do not trust. Our goal is to prevent malicious clients from building up state in memory (not allowed in our use case). I have gone through the documentation, some of the code and played around with the runtime. Here are my thoughts and questions:

1. I am thinking we would want to create a new execution environment for each execution so we can get a fresh WASM stack? Is the stack memset to 0 during initialization? Are there safeguards in place to prevent overflow attacks?

2. Since the heap is tied to a module instance, I am assuming we would need to reset memory on it manually. My first attempt was to use Alloc_With_Pool so the native app can control where the global heap memory is allocated. However, the mallocs done in the WASM code end up getting memory addresses (converted to native pointers) outside of this pool. My guess is that because I am running this on Linux, the memory is not allocated from the global heap:

If the memory access boundary check with hardware trap feature is enabled, e.g. in Linux/MacOS/Windows x86-64 by default, the linear memory is allocated by os_mmap from virtual address space instead of global heap.

Is there a way to get a handle on the dynamic memory allocated by the WASM module in the native context in this case? Or should we try to disallow dynamic memory allocations altogether.

There are a few more questions, but maybe we can start with this first!

Thank you!

[fridaymore]

I see Wasmtime has a zero-ing feature in the runtime (https://docs.wasmtime.dev/security.html#defense-in-depth):

Where it can Wasmtime will zero memory used by a WebAssembly instance after it's finished. This is not necessary unless the memory is actually reused for instantiation elsewhere but this is done to prevent accidental leakage of information between instances in the face of other bugs. This applies to linear memories, tables, and the memory used to store instance information itself.

Does WAMR have something like this?

[lum1n0us]

IIUC, wasm_runtime_deinstantiate() can release allocated resources during instantiation(include execution). If happen during module loading(usually runtime required), Other allocations will only be destroyed by wasm_runtime_unload() and wasm_runtime_destroy(). We might want to discuss that case by case.

[fridaymore]

It looks like wasm_runtime_deinstantiate would not reset the linear memory (memset zero) when releasing it. Would we be open to adding a flag that will memset the linear memory to zero prior to releasing it? I may be able to put up a PR for it.

[wenyongh]

Is it better to zero the memory by the developer himself? In fact, before wasm_runtime_deinstantiate, developer can get the start address and the size of linear memory by the APIs provided in wasm_export.h:

uint8 *mem_start_addr = NULL, *mem_end_addr = NULL;

/* Use app addr 0 to get the start address of linear memory */
mem_start_addr = wasm_runtime_addr_app_to_native(module_inst, 0);

/* Get the end address of linear memory */
wasm_runtime_get_native_addr_range(module_inst, mem_start_addr, NULL, &mem_end_addr);

memset(mem_start_addr, mem_end_addr - mem_start_addr);

[fridaymore]

Checking my understanding: if I have a C program with global / static variables that I compile to WASM, will those variables be in the linear memory's "data" section or somewhere else?

[wenyongh]

Yes, normally they are mapped to data section of linear memory.