-
Notifications
You must be signed in to change notification settings - Fork 428
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
ReseedingRng fork handling is ~~broken~~ not as expected #1362
Comments
I've been told that this was a CVE in openssl https://nvd.nist.gov/vuln/detail/CVE-2019-1549, so perhaps this should have been filed using the security issue template? Sorry if that's the case. |
From the
It turns out that ChaCha now uses a fairly large buffer: Adjusted, your code does as expected (notice that the last two outputs differ):
I.e. this behaves exactly as advertised. Now, I agree that this type of design compromise (a mixture of performance and security goals where the exact guarantees are less than obvious) is not ideal. This is why this issue was opened recently. What to do about it is under discussion. Also note: this is not a professionally funded library, just a community project (without even donation funding). Possibly we should try to change that but doing so would need support from more than just a few individuals. |
I guess. I think the code should change to regenerate the buffer (or clear the counter). There'd be no regression for the normal use, and you'd fix issues like this. You would want to only do this in the post-fork child, rather than in all 3 atfork callbacks, in order to not pessimize process spawning though. As it is, I don't really get why you'd bother with the fork handler. |
Given that Perhaps with atomics it wouldn't be too bad. Perhaps having an entirely thread-local RNG is just the wrong design anyway, especially considering how large a cache we use to maximise throughput benchmarks.
... yes. The buffer size increased over time, but still the only purpose is to make long-running processes eventually get independent RNGs. |
Removed in #1379 |
The ReseedingRng claims to protect against fork:
rand/src/rngs/adapter/reseeding.rs
Lines 292 to 302 in ef89cbe
Here's an example that shows that after
fork
, the parent and all child processes will still have the same state for the thread rng: https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=f63e9a09df0ec7f67d84dacb6d39ac32, which produces output like:I haven't dug deeply into why what you do currently is wrong, but it causes very tough to track-down bugs. CC @joshlf, who filed #1169, leading to the current design of the fork handling.
Background / why I'm stuck with fork: I have code that runs as a Postgres extension (https://github.com/pgcentralfoundation/pgrx), and PG will will run some init code in the parent, but most code runs in a child process (forked per-connection). Both used the
uuid
crate, which (apparently -- some dep in our tree seems to have turned it on) has afastrand
feature for using therand
crate. At the moment we've avoided use of uuids in that code (it didn't actually need them), but ifrand
is going to try to handle this at all, it might as well be right.The text was updated successfully, but these errors were encountered: