Skip to content
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

Closed

Conversation

briansmith
Copy link
Contributor

See the added comment for details.

Copy link
Member

@newpavlov newpavlov left a 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.

src/use_file.rs Show resolved Hide resolved
Copy link
Member

@josephlr josephlr left a 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,
Copy link
Member

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.

Copy link
Contributor Author

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.

Copy link
Contributor Author

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().

Copy link
Member

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!

@briansmith briansmith force-pushed the b/read_instead_of_poll branch from 629eb30 to 5a565b6 Compare June 3, 2024 01:19
@briansmith briansmith force-pushed the b/read_instead_of_poll branch from 5a565b6 to 3c8df25 Compare June 3, 2024 01:22
@briansmith briansmith marked this pull request as draft June 3, 2024 04:17
@briansmith
Copy link
Contributor Author

Please hold off on merging this. I initially underestimated the potential problem of draining the estimated entropy from /dev/random as I was only considering long-running processes and not many invocations of short-lived processes. I am going to investigate another approach.

@briansmith
Copy link
Contributor Author

Closing in favor of #452, which just adds the documentation from this.

@briansmith briansmith closed this Jun 4, 2024
@briansmith briansmith deleted the b/read_instead_of_poll branch June 4, 2024 01:53
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants