Jim Newsome

The effect on the tgen benchmark appears to be negligible: https://github.com/shadow/benchmark-results/tree/master/tgen/2023-09-26-T20-35-40 

The Tor benchmark seems to be a bit slower, as before, though it has an overlapping confidence interval with the weekly. https://github.com/shadow/benchmark-results/tree/master/tor/2023-09-26-T20-37-14 

gabi @ Tor has dug into this a bit and has some ideas: https://gitlab.torproject.org/tpo/core/arti/-/merge_requests/1399#note_2921626

It might be useful to look at arti's shadow CI test: https://gitlab.torproject.org/tpo/core/arti/-/tree/main/tests/shadow?ref_type=heads

It looks like the `tor` processes in the tor-minimal test do access this during initialization, though I'm not sure yet what it's used for. After enabling strace logging in the...

Using `strace -k` on a native execution of `tor`, it looks like this is being used by libevent to initialize its RNG. ``` openat(AT_FDCWD, "/proc/sys/kernel/random/uuid", O_RDONLY|O_CLOEXEC) = 3 > /usr/lib/x86_64-linux-gnu/libc.so.6(__open64+0x5b)...

Yup, definitely seems worth fixing :) It's a little more complex than e.g. `/dev/random` since it should produce valid UUID strings rather than just random bytes. i.e. probably needs its...

> i.e. probably needs its own `FileType` Actually maybe `FILE_TYPE_IN_MEMORY` would work, with a new file being created for each `open` operation on this path. That just leaves generating valid...

Most of this is cleaned up now, but we still end up having to create slices of possibly-uninitialized-bytes inside the MemoryManager, to pass to nix's wrappers around process_vm_readv and process_vm_writev....

I wasn't sure it's possible to make a statically linked `.so`, but it appears that you can. i.e. we should theoretically be able to make the shim completely statically linked....