Wasmtime-py and randomness

[whitequark]

I am using wasmtime-py to create a fully deterministic sandbox (for reproducible build purposes) for a toolchain. The toolchain uses rand() or similar for Monte Carlo method computations, which AFAICT requests randomness from wasmtime.

Is there a way to tell wasmtime to only produce deterministic randomness? Is that something I can do via wasmtime-py? What does it do by default?

[fitzgen]

I think this would involve implementing a new version of https://docs.rs/wasmtime-wasi/latest/wasmtime_wasi/bindings/random/random/trait.Host.html and plumbing that through to wasmtime-py but I am not super familiar with this side of the code base.

Maybe @pchickey can give a better answer?

[whitequark]

So I just noticed this comment:

Deterministic environments must omit this function, rather than implementing it with deterministic data.

In this case I suppose wasmtime doesn't actually need to do anything; rather, I would have to go through my dependencies and see where, if anywhere, they use get_random_bytes. Let me do that quick...

[fitzgen]

The other thing you can do is virtualize the wasi:random/random interface with a component that uses deterministic seeds.

[whitequark]

That is what I'm doing for the Node/web hosted YoWASP! It uses a reasonable PRNG (xoroshiro* or something like that), with a seed of 1.

But it seems like I'm violating the interface by doing so. I don't think the application should actually link to get_random_bytes because it's intended to be deterministic, so this could be arguably a nextpnr bug...

[alexcrichton]

In Rust the way this would be customized would be WasiCtxBuilder::secure_random as well as the WasiCtxBuilder::Insecure_* methods. Those aren't exposed in the C API at this time, so to get them over here in wasmtime-py that would need to be done first. It shouldn't be too too hard to have a void*-pointer-with-callback style API for configuring these though for wasmtime-py to use.

As for wasi:random/random, that's' related to WASIp2 and components primarily. I suspect @whitequark you're using wasi_snapshot_preview1 and random_get and that I think has a slightly more nebulous definition of security so I think it's ok to use a deterministic seed for that especially if you know it's not doing cryptographic things.

[whitequark]

I suspect @whitequark you're using wasi_snapshot_preview1 and random_get and that I think has a slightly more nebulous definition of security so I think it's ok to use a deterministic seed for that especially if you know it's not doing cryptographic things.

I am, yes. I'm running a compiler, if it's doing anything nondeterministically, it's a bug.

[alexcrichton]

Ok yeah in that case I think this is fine. Would you be up for helping to add the C API to configure this in Wasmtime?

[whitequark]

I think so--do you have a guide for doing that, or even just a similar PR? I can emulate it then.

[alexcrichton]

Sure yeah, bytecodealliance/wasmtime#8907 is a pretty recent example of adding a minor API. I'd recommend following the example of bytecodealliance/wasmtime#7209 for this API in terms of structures to add in the header.

We don't have many in-repo tests at this time for the C API so it's ok to skip those mostly and use wasmtime-py itself as the test instead.

[whitequark]

Thanks, I'll handle this when I have some spare time.