8 ms·
This is huge. Not only does it let you get entropy without having to open a device file (which has problems with chroots and file descriptor exhaustion), it al
by agwa 12y ago
This is huge. Not only does it let you get entropy without having to open a device file (which has problems with chroots and file descriptor exhaustion), it also provides the much-needed middle ground between /dev/random and /dev/urandom. Assuming this patch is applied (it's from Theodore Ts'o, so chances seem good), Linux will finally have a decent way to get randomness, which would make me very happy.
Hopefully proper fork detection will be next up.
- eropple 12y agoI'm familiar with what fork detection is (for those who aren't: a process can have the same PID as its grandparent, potentially exposing you to the risk of generating the same random data as the grandparent process), but can you elaborate on how you'd go about making it happen?
- agwa 12y agoOpenBSD 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.
- eropple 12y agoThat is really slick. Thank you.
- jeffmcjunkin 12y agoFurther 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 http://lists.openwall.net/linux-kernel/2014/07/17/707
- sarciszewski 12y agoThat is really awesome. Though it will be 2 more years before an Ubuntu LTS will support these features :(
- kwijibob 12y agoNot 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/ChangeSummary/12.04.4 https://wiki.ubuntu.com/PrecisePangolin/ReleaseNotes/ChangeS...
- sarciszewski 12y agoOh, 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]
- tcoppi 12y agoSeems like that functionality would better be included as separate madvise() advice than a new syscall, but probably a good addition either way.
- ramidarigaz 12y agoThe next email in that thread suggests using madvise() as well.
- panzi 12y agoI'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?
- simcop2387 12y ago
- icambron 12y ago> 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.
- TheLoneWolfling 12y agoA 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"...)
- rcthompson 12y agoBut at least if it lasts longer than your lifespan, you can be sure it will be someone else's problem when it goes wrong.
- nhaehnle 12y agoUgh. 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.
- nitrogen 12y agoThe page size is a minimum of 4KB, so you can't really allocate anything smaller from the OS.
- Someone 12y agoThat'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.
- nhaehnle 12y agoActually, 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.
- IgorPartola 12y agoWould it be possible to do something a bit more modern-feeling such as register a callback address that gets executed on fork?
- TheLoneWolfling 12y agoJust don't fork in that callback... Or call anything that potentially forks.
- JoshTriplett 12y agoIf you can count on pthreads, you can use pthread_atfork for that.
- taejo 12y agoThe 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.
- JoshTriplett 12y agoVery good point; pthread_atfork does not suffice. Thanks for the correction.
- KayEss 12y agoWhat's the reason for not keeping the PRNG data in a page of its own which is marked INHERIT_ZERO?
- sillysaurus3 12y agoit also provides the much-needed middle ground between /dev/random and /dev/urandom. What do you mean?
- agwa 12y ago/dev/urandom never blocks, even if it means returning randomness before the system has gathered enough entropy to safely seed a CSPRNG. /dev/random blocks whenever the system's "entropy count" is too low, even if the system has previously gathered enough entropy to produce secure randomness. The frequent blocking of /dev/random makes it unsuitable for practical use while providing questionable security benefit. getrandom() blocks only until the system has gathered enough entropy to safely seed a CSPRNG, and then never blocks again. (Assuming the GRND_BLOCK flag and not the GRND_RANDOM flag.) An in-depth explanation: http://www.2uo.de/myths-about-urandom/ http://www.2uo.de/myths-about-urandom/
- sillysaurus3 12y agoFrom your link: /dev/urandom is insecure. Always use /dev/random for cryptographic purposes. Fact: /dev/urandom is the preferred source of cryptographic randomness on UNIX-like systems. This seems to contradict your first point, which is that /dev/urandom is insecure in some situations. (Returning randomness without sufficient entropy is a security problem.) Can urandom ever be used insecurely? Tptacek has said many times that you should just seed /dev/urandom from /dev/random, then never use /dev/random again: http://hn.algolia.com/#!/comment/forever/prefix/0/author%3Atptacek%20urandom http://hn.algolia.com/#!/comment/forever/prefix/0/author%3At... Is LibreSSL's situation different? If so, why?
- agwa 12y agoFurther down, under "Not everything is perfect," the author addresses the problem with /dev/urandom never blocking. Seeding /dev/urandom from /dev/random is a trick that can be used early in the boot sequence to ensure that /dev/urandom is henceforth secure. (In practice, distros carry over a seed from the previous boot which accomplishes the same effect.)
- leccine 12y agoNSA likes this. Only one random and entropy code to compromise.
- agwa 12y agoAs opposed to putting a CSPRNG in userspace, in which case they only need to compromise either of two CSPRNG codebases?
- leccine 12y agoAs opposed to have everybody implement his/her own random()/entropy().
- awj 12y ago...the NSA would love that most of all. The vast majority of programmers lack the knowledge, skill, or both required to correctly implement anything related to cryptography.
- leccine 12y ago"The vast majority of programmers lack the knowledge, skill, or both required to correctly implement anything." Agreed.
- agwa 12y agoWho's "everybody?" If you mean userspace application/library developers, they don't have a good source of entropy, so they have to get it from the kernel. That means userspace CSPRNGs end up depending on the kernel CSPRNG. Presto, two single points of failure!
- leccine 12y agoI see, so prior to this random() and entropy() addition to Linux nobody could ever write any security related application. Yes, this is true. We should change the pull request to "Enable security for Linux, 2014". God, never too late...
- edwintorok 12y agoSo looks like on older kernels they can keep using the kernel.random.uuid sysctl, and on newer kernels this new syscall ... nice!