[NativeAOT-LLVM] Question: Is GetCryptographicallySecureRandomBytes allowed to block

[yowl]

I was thinking of implementing GetCryptographicallySecureRandomBytes with WASI's random_get

https://github.com/WebAssembly/WASI/blob/main/phases/snapshot/docs.md
(near the end)

This can block though, I'm not an expert, but I suppose that it blocks waiting for entropy. Is that OK for GetCryptographicallySecureRandomBytes ?

(I also need to check if emscrpten actually supports it when compiling for the browser.)

[jkotas]

This looks like a variation of the problem we have hit with the crypto APIs. dotnet/runtime#40074 has the details.

Is GetCryptographicallySecureRandomBytes allowed to block

How would you implement this block? I do not think it is possible, in browser at least.

[yowl]

Thanks for the link (my own selfish interest for this problem is outside the browser/JS world). I wouldn't implement the block myself, my understanding is the call to WASI random_get will block internally if there is not enough entropy.

Write high-quality random data into a buffer. This function blocks when the implementation is unable to immediately provide sufficient high-quality random data

Emscripten does not actually have an implementation for this (outside of its tests where it just returns the passed in buffer). So what I'm proposing is a change, in #ifdef at

runtimelab/src/libraries/Native/Unix/System.Native/pal_random.c

Lines 72 to 76 in 3dd23bf

	extern int32_t dotnet_browser_entropy(uint8_t* buffer, int32_t bufferLength);
	static bool sMissingBrowserCrypto;
	if (!sMissingBrowserCrypto)
	{
	int32_t bff = dotnet_browser_entropy(buffer, bufferLength);

Where for NativeAOT-LLVM, dotnet_browser_entropy would be replaced with random_get (the signatures are luckily the same). For emscripten targetting the browser, this would just be changing the undefined symbol from dotnet_browser_entropy to random_get, but for WASI this will allow (via #1845) the WASI function to be used.

An alternative approach could be to supply a .c file with dotnet_browser_entropy implemented as delegating to random_get and that could be linked in when targeting WASI. I guess I'm easy either way.

[jkotas]

I think it is ok for this experimental branch, but I am not sure whether this change would be upstreamable.