-
Notifications
You must be signed in to change notification settings - Fork 429
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
Potential issues in ReseedingRng #1169
Comments
I think the first issue is not a problem. Reseeding is not strictly necessary and on a "best-effort" basis. If it does not work, it's better to ignore the error and continue. |
I don't think that's true. If you fail to reseed on fork, then you end up with two processes which are both producing identical PRNG output until the next reseeding event. This may be a correctness issue for some applications, and it's certainly a security issue if the PRNGs are ever used in a cryptographic context ( |
Error handlingPanic-on-error does sound the most appropriate here. The one reservation I have is that, should any erroneous/incomplete posix impls return an error instead of implementing libc dependency@joshlf could you please be more specific since a search of the Worth mentioning also is that the fork protection already does not guarantee no duplicate bytes in the forked process, since the protection only applies from the next time |
This is what I meant with "best effort". Furthermore, it only works on POSIX platforms. You can't rely on I'm also worried about breaking rand for a lot of users. Under which conditions does |
It seems that However, does that mean we should only use |
Sure. libc itself uses the global allocator to perform certain operations, which includes both thread-local storage initialization and thread teardown. This has two consequences:
For global allocators, the issue is thread-local variables, not
Reading the
It looks like the entire |
This does not sound like a good idea: besides the potential allocation issue, any returned result may not be unique to the process even after fixing the issue you mention due to
Another point of interest is that the current implementation only logs a warning if, for some reason, reseeding fails (presumably if the call to |
Some other libraries - such as BoringSSL - handle this by aborting the process on the theory that, in practice, no code securely handles this case (and that it happens so rarely that aborting is acceptable). |
@joshlf the reasons we don't panic are two-fold: (1) And I think we can close this now? |
I think the original two issues are fixed by #1178. Please open a new issue if there is anything else that could be improved. |
There are two potential issues in this function:
rand/src/rngs/adapter/reseeding.rs
Lines 311 to 316 in ee1aacd
Error handling
The first is that, per the POSIX spec,
pthread_atfork
can return an error. This error should be checked (the code should probably panic on error because an error means that the handler has not been registered).libc dependency
The second is more speculative. If there's any way for libc's implementation to depend on
ReseedingRng
, then it's possible that libc code will call into aReseedingRng
after forking but before thepthread_atfork
callback has been called, which would result I've run into a similar issue before when writing a global allocator (see the alloc-tls crate for details).For this, I recommend registering the same callback for all three of
pthread_atfork
's arguments. This will result in the counter being incremented at the following points:fork
call, before any processing has begunfork
call, after all processing has completedfork
callIf the counter is incremented in these places, the only way for there to be a problem is if
ReseedingRng
is used in the parent in the middle of fork processing (after the first increment but before the second) and in the child before thefork
call ends (and thus before the child's counter is incremented). This isn't 100% guaranteed not to happen (and I haven't dug through anyfork
implementations to figure out whether it's likely to happen in practice), but it's the best you can do with whatpthread_atfork
makes available. If you wanted to be 100% certain, you could do something more custom - e.g., directly invoke syscalls to get your PID - but that's almost certainly too complex and brittle to justify hedging against something that will almost certainly never happen anyway.The text was updated successfully, but these errors were encountered: