Open briansmith opened 1 month ago
getrandom
from failing in the case where a sandbox blocks poll()
. https://github.com/unikraft/lib-musl/issues/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.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 #452]./dev/random
becoming readable will stall an application. We might want to provide similar guidance.__sanitizer_syscall_pre_impl_poll
and __sanitizer_syscall_post_impl_poll
?
- 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
ENOMEM
and neverEAGAIN
. Since this code is Linux-specific, should we remove theEAGAIN
case in the poll loop? Should we replace it with anENOMEM
case?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
.