Substituting syscalls

[kubkon]

Is it possible to substitute wasmtime's syscalls without modifying wasmtime-wasi sources, and in particular wasmtime-wasi/syscalls.rs?

For example, suppose I wanted to forbid the random_get syscall from accessing the host's source of entropy. Is modifying

pub unsafe extern "C" fn random_get(...)

the only way to achieve this? I've had a stab at this, and that's how I achieved this: kubkon/wasmtime. Please bear in mind that this is a simple proof-of-concept, nothing more.

I was thus wondering if there was perhaps a more elegant way of achieving the same, especially such that didn't involve modifying the core of wasmtime-wasi.

Thanks in advance!

[sunfishcode]

It's not something the current code specifically anticipates, though it's something we could consider.

It might make sense to have some higher-level modes that users could select from. For example, a deterministic mode, which makes random_get return deterministic data, and also enables the NaN canonicalization flag in Cranelift.

As another idea, one of the things I expect that will happen with WASI soon is that it'll be split up into multiple modules. If all random-generating functions are in their own module, it would be fairly straightforward to have different module implementations that could be plugged in.

[kubkon]

Yep, precisely, a deterministic mode would be a great thing to have, and I really like the idea of having multiple plug'n'play modules. In fact, to provide some context, @golemfactory we're in the process of rolling out a WASM sandbox which underneath is using SpiderMonkey (wasm32-unknown-emscripten target, see here), and in order to be able to cross-verify the results of some program calculated by two different nodes, we're after purely deterministic computations so that we can compare them in some way. But, as you know, compiling to emscripten and running it outside of the browser is less than ideal, and we'd much rather have a WASI sandbox.

Anyhow, I'd be more than happy to help out in modularisation of WASI as well as introducing a deterministic mode if it's on the roadmap. Just shout out!

[kubkon]

I'll close the issue for now then, and when the time comes, we can either reopen it or simply reference it from the new one with a concrete plan of action.

[sunfishcode]

Sounds good.

Thinking about this a little more: making random_get return deterministic results has the risk that applications may still assume they're getting actually random data. In cases like that, it's probably best to just make that function unavailable when determinism is required.

[kubkon]

That's an excellent point. If it would generate a compile-time error, it'd be perfect as then the WASI developer would know what is/isn't supported early on in the development process. The problem we have with our current WASM sandbox targeting emscripten, is that the availability of the entropy is not resolved until the runtime which is simply too late for my taste, and hence, why we've had the entropy emulated as a polyfill. Having said all that, I think I'd actually much more prefer a complete exclusion of the random_get function and compile-time errors.