WaspVM - Run WebAssembly in Elixir

Huh, this is really cool. Interesting sandbox method to let basically anyone run untrusted code. Not super performant since WASM doesn’t map to the BEAM very well but perfectly good for most untrusted code. I may make use of this.

Thanks! Yeah performance won’t reach what you’d get with a closer to native language like C or Rust, (at least not if you’re only executing one VM at a time), but it allows you to sandbox your code like you said. Although we haven’t actually benchmarked this yet, I’m thinking it outperforms C and Rust when running multiple VMs though (like running 10 different Wasm at the same time, which is what we’ll be doing in elixium). Let me know if you end up doing something cool with this!

Not looked deep in to it yet but a couple of questions.

How does it handle a call running ‘too’ long, like can you enforce a maximum ‘reduction’/op-calls count or should we just shunt it into it’s own beam actor and kill it if it takes too long.

Is there a way to pause and later resume a running call?

WASM doesn’t define Perfect TCO yet, but does this support PTCO (the BEAM does)?

Is there a way to serialize out the state of the ‘program’ and reload it where it left off later (outside or inside of a function call)?

There’s a system which let’s you specify a maximum gas limit to prevent programs from running too long, it’s in one of the pull requests and is scheduled to be added to the next version. Basically each instruction has an associated cost to run, and this cost gets accumulated while the program is running – if the accumulated amount gets higher than the limit specified the program halts.

There’s currently no way to pause a call, but I suppose that should be easy enough to implement, depending on how that’s meant to work

The frames aren’t actually being dealt with as a stack, they’re just using elixirs built in recursion on every function call. I don’t recall if we’ve tail call optimized yet but I do know that we can call wasm functions recursively millions of frames deep with no issues.

There’s no serialization at the moment, although that’s something that could also be pretty easily implemented, but I don’t think that’s a goal of Wasp – as it depends on the user to validate that the serialized state is valid and non malicious, which opens up an attack vector

Elixir/Beam’s stack handling is like the heap, but they start on opposite ends and grow toward each other, consequently a recursive function calling itself many times and keeping the args compared to one using TCO to call itself but keeping args in a list the TCO one will actually be slightly slower because of the list operations and popping the frame, but they use near about the same memory, so that is not an issue unlike on metal languages regardless.

As long as the VM’s recursive calls are TCO then you should just about get TCO for free though.

I’m not thinking serialization of the program back out, I mean it’s memory state. Like it would be convenient to be able load a users, say a game object state that they program, it runs around for a bit, and eventually gets unloaded and serialized to a database for a bit, but then the user logs back in so it gets unserialized and its memory is restored to just how it was left off, thus picking up where it was in its own program.

Ahh I understand. What we need in order to make this possible is to expose an API for interacting with the Wasm virtual memory, the way the browsers allow you to do so. This isn’t specified in the spec but it’s a feature that makes sense to have. I’ve created an issue for this here, leave a comment on there if you want to claim the task, otherwise it’s open to anyone.

Essentially if I can just :erlang.term_to_binary/1 then :erlang.binary_to_term/1 to serialize out then in an entire interpreter, that would be awesome. Though a better defined version that only serializes what is necessary would be far superior.

Of course the term/binary conversions would fail if the interpreter is spawning multiple erlang processes (I’m not sure it should).

Direct serialization / deserialization support within the VM itself isn’t something that I feel needs to be in the VM itself, the only state that the VM really holds is instruction pointers and memory mappings, and the feature that gives direct access to memory through an API would leave just the instruction pointer as a piece of state that could be exported / imported – but I don’t see any real value in this. At the most it’d let users pause / play through the VM as it cycles through instructions (which is something we could directly support without serialization).

There exists a way to view the VM state in a read-only way if someone wanted to run diagnostics, but importing VM state probably wouldn’t be that useful, unless there’s a use case I’m not seeing?

Like the one I listed above, say someone wants to make a game where they write code to control a little in-game tank or so, they upload their wasm to the server and the server runs it, when they log out then eventually their little moving tankbot is paused and serialized out, full state of the wasm interpreter for it, and later when they log back in then it is reloaded right where it left off. Lots of little cases like that.

Right but that state would be stored in the Wasm modules memory, which can be read and written from elixir. Either way elixir is going to need to initialize a new VM, so they can write to memory from their elixir code upon VM initialization