Hacker News Reader

Comment by agwa | Hacker News Reader

OpenBSD lets you use the minherit() syscall with the INHERIT_ZERO flag to specify that a page of virtual memory should be replaced with an all-zero page in the child process after a fork. During initialization of the PRNG, you map an anonymous "canary" page, put a non-zero byte in it, and tag it with INHERIT_ZERO. To check if a fork has occurred, you read the byte. If it's zero, a fork has occurred and you need to reseed the PRNG. This is airtight, unlike comparing getpid() against the last PID seen by the PRNG.

Another approach would be giving every process an ID that never repeats and is unique across all namespaces, and use that for comparison instead of the PID.

View on HN

Further on in that same thread, Bob Beck just asked about adding minherit() functionality[1] to Linux as well. LibreSSL might end up adding some very useful syscalls to Linux, which helps with their portability and helps future Linux userland programs in the same situation. Win-win!

[1] http://lists.openwall.net/linux-kernel/2014/07/17/707

That is really awesome. Though it will be 2 more years before an Ubuntu LTS will support these features :(

Not necessarily. Ubuntu have "enablement stacks" kernel updates for the LTS releases. These are more than just upstream patches.

For example, 12.04 LTS release had 12.04.4 with a backported kernel as a standard update.

https://wiki.ubuntu.com/PrecisePangolin/ReleaseNotes/ChangeS...

Oh, and here I thought they just patched security holes but kept the same old kernel for 2 years. [insert "the more you know" graphic here]

Seems like that functionality would better be included as separate madvise() advice than a new syscall, but probably a good addition either way.

The next email in that thread suggests using madvise() as well.

I'm a noob concerning all of this, but how would it be different to MADV_DONTFORK? Or why can't MADV_DONTFORK be used for the same task?

MADV_DONTFORK ends up working a bit different, when the forked process tries to read the page it ends up as a segmentation fault because the page wasn't carried over. It can be made to work but that ends up more difficult since you have to trap that signal and be able to prove you aren't going to catch a real one. Adding something like INHERITZERO would end up giving you a new blank page which would be much nicer to deal with in the userspace.

> MADV_DONTFORK ends up working a bit different, when the forked process tries to read the page it ends up as a segmentation fault because the page wasn't carried over. It can be made to work but that ends up more difficult since you have to trap that signal and be able to prove you aren't going to catch a real one.

Doubly difficult from within library code that needs to work in arbitrary programs, and thus cannot mess with signal handling.

There's a real need for per-memory-range segfault handlers.

I see.

Ugh. Whatever happened to not wasting an excessive amount of space? Allocating 4KB for what is essentially a single bit flag seems like a needless waste of space, especially given that we already have syscalls that set up triggers to manipulate individual words in userspace (most prominently, the futex syscall, but there are others).

I suppose that if the state of your PRNG neatly fits into (almost) a multiple of 4KB, it makes sense to allocate that space explicitly and put a guard bit in there, then mark the entire region as INHERIT_ZERO. This has the added benefit of making it less like that PRNG state is leaked somewhere.

The page size is a minimum of 4KB, so you can't really allocate anything smaller from the OS.

That's the OP's point. His/her question is: why allocate an entire page if, instead, you could have a single bit 'process did not initialize its source of randomness yet' in kernel space per process?

The only advantage I see is that the current solution allows one to implement the random number generator independently of the kernel. Introducing that bit creates a tight coupling.

Actually, there's an even better solution: simply give the kernel a userspace address range which will be zeroed on fork. There's simply no reason at all why this address range should be restricted to exactly 4KB or a multiple thereof (one could imagine the kernel doing some page-table tricks to avoid a full memset() for large areas, but that's an optimization that can be added transparently to an API that supports arbitrary address ranges).

The futex API (including set_tid_address) is precedence for this kind of syscall.

> Another approach would be giving every process an ID that never repeats and is unique across all namespaces, and use that for comparison instead of the PID.

This seems like a nice choice. PRNG seeds aside, it's always bothered me that processes aren't uniquely identified, which makes monitoring them kind of a pain.

A 64-bit process ID would allow that.

Well, currently. (~585 years to overflow at 1 billion PIDs/sec. Seems absurd, but then again, there are so many cases where we've gone "this should be good enough"...)

But at least if it lasts longer than your lifespan, you can be sure it will be someone else's problem when it goes wrong.

What's the reason for not keeping the PRNG data in a page of its own which is marked INHERIT_ZERO?

Would it be possible to do something a bit more modern-feeling such as register a callback address that gets executed on fork?

Just don't fork in that callback... Or call anything that potentially forks.

If you can count on pthreads, you can use pthread_atfork for that.

The problem with that is that a library can't count on pthreads: the application might call clone directly, without going through the libc wrapper, which calls the atfork callbacks.

Very good point; pthread_atfork does not suffice. Thanks for the correction.

That is really slick. Thank you.

Reply on news.ycombinator.com