-
Notifications
You must be signed in to change notification settings - Fork 184
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Linux/Android: Read a byte from /dev/random
instead of polling it.
#449
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks fine to me. I will wait for @josephlr to take a look at it.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good to me!
// Poll /dev/random to make sure it is ok to read from /dev/urandom. | ||
// Read a byte from /dev/random to make sure it is ok to read from | ||
// /dev/urandom. reading a byte instead of polling is more compatible with | ||
// sandboxes that disallow `poll()` but which allow reading /dev/random, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think this sounds reasonable, but do we have any documentation or examples of sandboxes which have this issue? It's not obvious to me that read
-ing from an open file descriptor would be better or worse than poll
-ing or select
-ing it.
The reason for the current implementation (discussed in #58 and briansmith/ring#558 (comment)) is to avoid "debiting" a single byte from the /dev/random
"entropy estimate". Both libsodium and openssl try to avoid this read:
Personally, I think the downside of reading one byte from the /dev/random
pool is not that bad, and I prefer the simplicity of this approch. I just want to understand why select
/poll
is not a good fit in practice.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I just want to understand why select/poll is not a good fit in practice.
I am submitting this change is because I have to write documentation about how to configure sandboxes and when one can avoid doing pre-sandbox initializations. In investigating this, I found that it is actually really difficult to document the seccomp policy for poll
. The Chromium sandbox has conditional logic for __NR_POLL vs __NR_PPOLL for example. I added some more commentary about this in the comments of this PR.
I am also trying to ensure that if somebody is already using OpenSSL (or a fork of it) then switching to a getrandom
-based library will not affect their sandbox policies.
So, in some sense it is hypothetical, but that's mostly because I write libraries for orgs who make frameworks for people who product applications.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
openssl uses select() by default but can be configured to use read()
OpenSSL uses select()
unless there are too many file descriptors open, in which case it will use read()
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Those additional comments look great! Thanks for the explanation, makes sense to me!
629eb30
to
5a565b6
Compare
See the added comment for details.
5a565b6
to
3c8df25
Compare
Please hold off on merging this. I initially underestimated the potential problem of draining the estimated entropy from |
Closing in favor of #452, which just adds the documentation from this. |
See the added comment for details.