Post #2553677

2025-11-11 18:15 UTC

@sunfish@hachyderm.io You might want to do deterministic replay for record-replay debugging. Or you might want to record the random numbers used to derive a TLS encryption key to make wireshark work. Or you might want to get a bunch of random numbers once and then run the same computation using those random numbers on multiple systems to check they match. All of these can be done by virtualizing the random-number generator, but require wasm runtime integration if random numbers were part of the component model. Edit: and to add none of these match the secure vs on-secure rng distinction. for all of them you do actually want to virtualize the secure rng too.

Replies (2)

@esoterra@hachyderm.io 2025-11-11 18:26

@bjorn3@hachyderm.io @sunfish@hachyderm.io maybe this kind of thing should require help from the runtime though so you know your RNG sources aren't getting messed up or intercepted in basic composition scenarios.

Open ##2553678
@sunfish@hachyderm.io 2025-11-11 19:13

@bjorn3@hachyderm.io There's a lot here that I don't have time to fully explore; here are a few quick thoughts: Debuggers are special. Debuggers can observe things that the spec says "can't" be observed. They can mutate "immutable" things. And they can break API contracts. Debuggers will have flexibility, even if the spec doesn't explicitly say so. Regular virtualization means changing what imports/exports are linked to. But there are a number of things users want to do that can't be done through linking: you can't catch traps, you can't impose CPU/memory/etc. quotas, and so on. So maybe there will need to be some additional mechanism, and this something might also be a place a builtin random facility could be controlled.

Open ##2553680