The sandboxing implementation as currently implemented is Linux-only.
The zero dependencies claim was more of a “we don’t depend on much external Rust code”, and not a “this is completely OS independent”. We still depend on the OS, mostly for sandboxing.
As far as Windows support goes, there are a few options:
- Run an interpreter. This doesn’t recompile the program into native code and is very simple, so it doesn’t need any extra sandboxing. This already works and is supported today.
- Run the guest program in a
wasmtime-like sandbox. This will also work on Windows, but it’s nowhere near as secure. This is currently not implemented, but I might add it in the future. - Run the guest program under a system-level virtual machine (e.g. Hyper-V on Windows). This would be as secure as what we have under Linux, but will require highly OS-specific code. (And I’m not a Windows expert so I don’t know off the top of my head how feasible that is. I’d like to experiment with it in the future though.)
By definition a recompiler which emits native code cannot fully run inside of a WASM runtime.
The VM could run inside of a WASM runtime as an interpreter, but we want to run it outside (because we want to maximize the performance) and we’ll expose this through appropriate host functions that the runtime will be able to call to instantiate the VM.
If you’re wondering whether you’d be able to use this inside smoldot - yes. You’d just include it as a dependency, and it’d work out-of-box. If the target for which the VM is compiled is not explicitly supported by the recompiler it’ll just automatically fall back to use the interpreter. (It will be slower of course, but I assume light clients are not going to run heavy computations through it, right?)
For the runtimes it’s not completely out of the question, but at this point in time - no, there are no plans. Currently we’re doing this strictly for smart contracts, however the VM itself is pretty much a general purpose VM - it’s designed so that it should be able to check all of the boxes which smart contracts need (e.g. it’s already as fast as the fastest singlepass WASM VM), but it’s not constrained by those needs and could, in theory, be used for full fat runtimes.
So what’s planned is that we will experiment with running normal runtimes on it, and depending on the results we can have a “should we also switch our runtimes to it?” conversation, but at this point it’s not clear whether it’d be worth it. It’s pointless to switch just for the fun of it, and there must be clear benefits of doing so.
Indeed! For a single model of a CPU maybe it could be possible (but extremely hard), but for multiple? It’d be just impossible, since every model will be slightly different.
That said, there are certain microarchitectural properties that essentially all modern high performance CPUs share, and will have for the forseeable future. The example I cited in my post with cache associativity is something that, I think, will change (e.g. due do different cache sizes, different N-ary associativities, etc.), so it wasn’t the best example of what we could try to model.
However, for example, every modern high performance CPU is superscalar, and this is something that, I think, might be relatively easy to model. Of course the objective here is not to “model exactly what CPU does”, but to “model it a little bit more accurately”. So the simplest idea that we could try here: instead of looking at single instructions look at pairs of instructions, see if they’re independent, and if so assume the CPU can run them in parallel (and essentially every modern CPU will do this, with a few exceptions). So we’d still get 100% deterministic results, but they would match the reality a little bit better.
(Of course, how much this would help is still an open question and needs to be benchmarked.)