Potential improvements to use of /dev/random on Linux/Android

[briansmith]

• 1. The man page says that Linux returns ENOMEM and never EAGAIN. Since this code is Linux-specific, should we remove the EAGAIN case in the poll loop? Should we replace it with an ENOMEM case?
• 2. The man page directs the user to note that poll may return "spurious readiness notifications" where poll indicates the file is readable when it actually isn't. Especially in the case of pre-getrandom-syscall-capable Linux versions, are such spurious readiness notifications possible? If so, this would be counter to the goal of polling but not reading /dev/random.

[briansmith]

• 3. PR Linux/Android: Read a byte from /dev/random instead of polling it. #449 and PR Linux/Android: Improve sandbox compatibility when checking /dev/random. #450 both attempt to prevent getrandom from failing in the case where a sandbox blocks poll(). poll returns ENOSYS unikraft/lib-musl#58 describes such a case. Interestingly, they note that libstd internally uses poll in some situations. The libstd code is especially interesting because it bails out to a fallback path on EINVAL, EAGAIN, or ENOMEM instead of retrying. https://github.com/rust-lang/rust/blob/master/library/std/src/sys/pal/unix/mod.rs#L101-L113 shows this, updated to address the Unikraft issue.

[briansmith]

• 4. The above PRs mention a few syscalls that poll() may be mapped to. ppoll_time64 is available from Linux 5.1+. Thus, people may need to update their seccomp filters to work on Linux 5.1. In any case, if we're going to document seccomp compatibliity anywhere then we should mention this in that documentation. [Edit: Addressed in PR Linux/Android: Document /dev/random polling considerations. #452].

[briansmith]

• 5. https://doc.libsodium.org/usage#sodium_init-stalling-on-linux notes that even on pretty new Linux kernels, in certain environments that seems actually increasingly important, blocking on /dev/random becoming readable will stall an application. We might want to provide similar guidance.

[briansmith]

• 6. See https://github.com/llvm/llvm-project/blob/3b2df5b6ee81cf2685c95728ff1baf795051c926/compiler-rt/include/sanitizer/linux_syscall_hooks.h#L1182-L1185. When sanitizers are enabled, it seems like we should be calling __sanitizer_syscall_pre_impl_poll and __sanitizer_syscall_post_impl_poll?

[josephlr]

6. See https://github.com/llvm/llvm-project/blob/3b2df5b6ee81cf2685c95728ff1baf795051c926/compiler-rt/include/sanitizer/linux_syscall_hooks.h#L1182-L1185. When sanitizers are enabled, it seems like we should be calling __sanitizer_syscall_pre_impl_poll and __sanitizer_syscall_post_impl_poll?

It seems like they also have methods in there for read, open, and close. I'm wondering if sanitizers being enabled just requires using a libc that has been modified to make those particular calls