Needs tests for the new utility

CodSpeed Performance Report

Merging #5444 will not alter performance

_{Comparing yagiz/buffered-entropy-source (f69afd4) with main (27391e9)}

Summary

✅ 34 untouched
⏩ 9 skipped¹

This design based on EntropySource isn't what I had in mind. I think we should define a simple global function like:

void getEntropy(kj::ArrayPtr<byte> output);

This should use a thread_local buffer in its implementation.

Then we can replace all the RAND_bytes calls with this.

This makes the change light-touch with no need to change any design around EntropySource.

Point raised from the security team: is forking an issue here? Specifically, if the process is forked after the cache is populated, the cache for the current thread will be duplicated in the fork. We either need to (a) require that the cache is only populated after forking happens or (b) refresh the cache when forking happens.

Point raised from the security team: is forking an issue here? Specifically, if the process is forked after the cache is populated, the cache for the current thread will be duplicated in the fork. We either need to (a) require that the cache is only populated after forking happens or (b) refresh the cache when forking happens.

FWIW, since this code is most likely invoked in the sandbox, it shouldn't be forking. We avoid forking in a process that already has additional threads, since another thread could be holding locks that would never release in the new process. In the past, this has typically manifested as "interrupt" signals in tcmalloc functions.

This code should be called strictly post-fork, but we should nevertheless add some debug checks to verify that the value returned by getpid() hasn't changed -- and just crash if a change is seen. If we see such a crash in tests, it means there's some pre-fork call to getEntropy() that needs to be removed.

We should skip these checks in release builds as getpid() is a syscall which is expensive.

Applied the pid check, rebased and force pushed.