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

WIPEONFORK [Linux] #59

Closed
dhardy opened this issue Nov 23, 2017 · 4 comments
Closed

WIPEONFORK [Linux] #59

dhardy opened this issue Nov 23, 2017 · 4 comments

Comments

@dhardy
Copy link
Owner

dhardy commented Nov 23, 2017

We could maybe make use of this, e.g. as a wrapper around a CSPRNG:
https://aws.amazon.com/blogs/opensource/better-random-number-generation-for-openssl-libc-and-linux-mainline/

Unfortunately it sounds like it's only available on one platform.

@pitdicker
Copy link

I think this could work well as part of ReseedingRng.

For WIPEONFORK to work you need to check some value against zero, and need to have a seeding RNG. ReseedingRng already needs to check a bytes_generated counter against generation_threshold, and has a reseeder. We would just have to invert the counter and back-off logic. That may even make it slightly faster, because comparing against 0 is slightly faster than checking against a value.

Is failing to reseed after a fork a case we want to handle, or exceedingly rare? We are talking here about a feature for a very recent Linux kernel version, and for OpenBSD. Both have an OS RNG that is supposed to be infallible. And if ReseedingRng is combined with ReseedWithNew it will have JitterRng as a backup. So I think we do not need to do something extra to the error handling ReseedingRng already has.

Advantages of using a custom wrapper:

  • Two pieces of functionality are nicely separated.
  • It is possible to have only WIPEONFORK protection without the need to increment a counter.

Advantages of using ReseedingRng instead of a custom wrapper:

  • I think there is an overlap in the situations where you want the extra fork safety, and the extra defense of occasionally reseeding.
  • No extra performance overhead when you want to have both reseeding and WIPEONFORK protection.

@dhardy
Copy link
Owner Author

dhardy commented Dec 15, 2017

It's possible to have the WIPEONFORK protection with ReseedingRng even without extra reseeding: just set the reseed threshold very high. The converse isn't true unless WIPEONFORK is configurable, but I can't see why users would not want this if using ReseedingRng. So sounds like a good idea to me.

@pitdicker
Copy link

I have experimented with this, but couldn't get it to work yet on Fedora 27. I am not sure if it was my code, or if the necessary libraries are not yet recent enough.

@burdges
Copy link

burdges commented Apr 5, 2018

Isn't WIPEONFORK applied to entire pages? Is there any scheme for aggregating allocations that want similar page flags?

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

3 participants