Replace wasi-libc's guest PRNG with a call to __wasi_random_get.

[sunfishcode]

Always call __wasi_random_get rather than doing a guest PRNG, because Wasm engines may snapshot or even clone Wasm state, which we don't have any visibility into.

We therefore effectively expect that __wasi_random_get is "fast", presumably using a PRNG-style implementation rather than a slower raw-entropy-style implementation.

[yamt]

We therefore effectively expect that __wasi_random_get is "fast", presumably using a PRNG-style implementation rather than a slower raw-entropy-style implementation.

have you made a research if existing implementations are "fast" as expected here?

[sunfishcode]

I have not made a comprehensive survey, but it's common for implementations to use sources such as /dev/urandom or getrandom which use PRNGs rather than raw entropy.

[yamt]

I have not made a comprehensive survey, but it's common for implementations to use sources such as /dev/urandom or getrandom which use PRNGs rather than raw entropy.

ok. thank you.

[vapier]

i'm not following the logic here

what implementations are you referring to ? getrandom() isn't supported by wasi-libc. it supports getentropy(), but that's just a direct call to __wasi_random_get() which requires a WASM<->runtime(JS) transition on every call. /dev/urandom requires filesystem syscalls which is also a WASM<->runtime(JS) transition. basically any call to wasi-libc for random data is now a syscall. going back & forth isn't what i'd call cheap or fast.

i saw one application make 1500 random calls during its startup which wasn't noticeable when wasi-libc had the PRNG, but now that each is transitioning, the overhead was noticeable enough that it made me dig into why the program was suddenly slow. I ended up optimizing that project to fill a large buffer with a single call, but I'm seeing other programs commonly generate random integers in the normal course of things. as in, it wants a random 8-bit (1 byte) at a time. this isn't something I can optimize away.

no, these are not my programs, but off-the-shelf OSS/POSIX projects.

i'm not seeing why this is a concern in the first place. if wasi-libc isn't allowed to store state because the runtime might snapshot the module, then how is that unique to the random state ? where is the discussion backing this decision ?

[yamt]

this change has been made with an assumption that __wasi_random_get is fast enough.
now we received a feedback saying it was not really true.
i guess we should consider a revert.