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

Fallback to super basic RNG in weak_rng if OsRng fails #180

Closed
Manishearth opened this issue Oct 18, 2017 · 9 comments
Closed

Fallback to super basic RNG in weak_rng if OsRng fails #180

Manishearth opened this issue Oct 18, 2017 · 9 comments

Comments

@Manishearth
Copy link
Contributor

rust-lang/rust#44911 is a thing. Rayon uses weak_rng (for something? idk), and weak_rng will crash if the OsRng fails. Perhaps we should do something like take the system time and run it through some mixer in that case?

@dhardy
Copy link
Member

dhardy commented Oct 18, 2017

We already have a rough suggestion to use the system clock as a fallback (see end of this comment).

@cpeterso
Copy link
Contributor

Some backstory: in Firefox bug 1409444, we are hitting weak_rng panics because OsRng fails for a few hundred Windows 7 users. This problem seems to be related to "corrupted DLLs" or anti-virus software.

weak_rng should probably fall back to a weak seed on all platforms, not just Windows [7]. We've hit other OS RNG problems (not Rust or weak_rng specific) such as Firefox for Android failing to open("/dev/urandom") because the OS temporarily ran out of fds on some CI test machines (Firefox bug 1409444).

@sfackler
Copy link
Contributor

At that point, should we just move entirely off of OsRng and on to the system clock or whatever?

@dhardy
Copy link
Member

dhardy commented Oct 19, 2017

No, it's worth using OsRng where available (unless you really don't care about random number quality).

But what's Firefox using random numbers for — presumably cryptography? In this case using a low-entropy source like the system clock is really not ideal.

@cpeterso
Copy link
Contributor

At this time, Firefox just uses weak_rng in the rayon and parking_lot schedulers (and in some Rust test code).

Also, @Manishearth changed Firefox's HashMap seed to use an RNG other than OsRng because we were hitting these same Windows panics.

@Manishearth
Copy link
Contributor Author

To be clear, I changed the hashmaps used by Stylo to not use an RNG/cryptographically secure hasher and instead use FNV hash since hashmap DOS is not a problem for browsers.

@dhardy
Copy link
Member

dhardy commented Oct 20, 2017

Right, well this is definitely something we want to fix with the rand refactor, but I suspect any changes coming through that will take a while (waiting for at least two RFCs to get merged, first 2152 which is still getting worked out, then weak_rng/ thread_rng changes).

cpeterso added a commit to cpeterso/rand that referenced this issue Oct 24, 2017
@Manishearth
Copy link
Contributor Author

cpeterso added a commit to cpeterso/rand that referenced this issue Oct 25, 2017
@cpeterso
Copy link
Contributor

Sandbox: Unexpected EOF, op 0 flags 02100000 path /dev/urandom
thread 'StyleThread#3' panicked at 'weak_rng: failed to create seeded RNG: Error { repr: Os { code: 5, message: "Input/output error" } }', /builds/worker/workspace/build/src/third_party/rust/rand/src/lib.rs:898:18

Manishearth is pointing to a Firefox test failure where weak_rng panicked because StdRng::new() failed to read /dev/urandom on Linux.

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

No branches or pull requests

4 participants