How rust is dealing with string in memory from its own runtime in webassembly?

help
1

Hello,

I am trying to understand how rust is allocating its own string in webassembly.
From what I understand, rust is using the stack memory for its own stack memory allocation.
I can't find any information about how it is using its heap.

I found a lot of answers about linear memory in webassembly and the result is that I think rust is writing all its heap to linear memory. But what if someone erase all the linear memory from javascript side ? It seems the wasm module will be corrupted !

So is linear memory only used to share data between rust and javascript or does the linear memory share sensitive rust engine data ?

Thank you in advance for your answers.

2

Linear memory is indeed used for the heap. It is also used to store locals that have their address taken. (eg let a = 42; let b = &a; will store a in linear memory) Manipulating linear memory from javascript is as safe as using the native debugging mechanisms (eg ptrace) on other systems to write to the memory of a process. Rust can't protect you against this kind of stuff. The only way to protect against this would be to use for example Intel SGX to create a secure enclave to run the code in.

1 Like
3

Thank you very much.
Now, I know the only way to share data between webassembly and javascript is to let the webassembly control the process.
I don't know much about Intel SGX, but why webassembly doesn't implement a table which list all pointers and length where javascript is granted to play with that part of memory (for one time then free by webassembly engine or static: never destroyed): a kind of mini GC. If javascript is trying to access a denied part of linear memory, then an error is generated.

1 Like
4

I think this isn't done because WASM is explicitly a minimal viable product. It is not intended to be as nice as possible, instead it's meant as a base on which other things can be implemented.

The initial WASM MVP is explicitly minimal because one of its goals is to be easily implemented by browsers. To gain wide adoption, it needed to be as simple as possible - and it's succeeded at that.

Now, we could add this in the next version of the WASM spec. But I don't think it would really add anything useful. Sure, it would protect a novice WASM/JS developer from messing up WASM memory accidentally, but how helpful would it be in actual applications?

All real applications will likely use something like wasm-bindgen, stdweb, or emscripten, and just have all the automatic translations and protections provided. And if you're worried about incorrect code causing errors, then I don't think this mini GC would really help - most languages which compile to WASM have unsafe capabilities, and can just as easily mess up their memory alone, without JavaScript's help.

All the things it could protect against shouldn't ever happen with automatically-generated JS wrappers to WASM code. And all it'd add is a performance hit for registering these regions, and validate the JS code. It would definitely useful as a debugging tool to be used like valgrind, but I don't think it would fit too well in regular application deployments...

1 Like
5

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.