15 ms·
The getrandom(2) system call was requested by the LibreSSL Portable developers
- easytiger 12y agoWhy? So in future they can complain they can't control the entropy sources?
- agwa 12y agoThis 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.
- 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!
- kps 12y ago> The getrandom(2) system call was requested by the LibreSSL Portable > developers. It is analoguous to the getentropy(2) system call in > OpenBSD. Oh the joy of NIH.
- aylons 12y agoI didn't understand what you meant by you commentary. The above excerpt shows they assuming upfront that they got the idea from BSD. As a system call is not an application that may be ported, they need to recode it. If the point was the name change, I guess this is only to keep consistency within the system, and far from a problem.
- tptacek 12y agoThey took the sane design from BSD ("here's a single system call that gives you crypto-safe entropy") and effectively made a family of system calls that replicate all the pointless drama of /dev/random and urandom. The NIH criticism is valid.
- clarry 12y agoIt seems pointless indeed. On the other hand, I'm almost glad the overengineering only went that far. Actually I'm expecting much worse after reading Theodore's ideas on the IETF list.. we'll see what kind of a library interface they'll come up with, if they make something besides getentropy(). But if we get all applications to use the same library, we can abstract away not only differences in operating system but also security policies vis-a-vis DRBG/NDRBG blocking/nonblocking. So what *I* would prefer is a library interface where the application declares what it wants the random numbers for: * Monte carlo simulations * Padding * IV * Session key * long-term key etc. The library can then decide whether or not the overall system policy should force application to block when generating long-term keys, ala gpg, or whether it should getting non-blocking entropy directly from the kernel, or whether using a userspace DRBG which is initialized from kernel-supplied entropy is the right answer. From https://www.ietf.org/mail-archive/web/dsfjdssdfsd/current/msg00120.html https://www.ietf.org/mail-archive/web/dsfjdssdfsd/current/ms...
- egwor 12y agoIn the synopsis, it says "It should not be used [by] Monte Carlo simulations or for other probabilistic sampling applications." Does anyone know why not?
- colanderman 12y agoProbably because it will be slow and deplete the entropy pool. Statistical sampling doesn't require cryptographically-secure random number generation.
- lomnakkus 12y ago"deplete the entropy pool" isn't really a meaningful phrase given the way the Linux /dev/{random,urandom} work. AFAIK /dev/random and /dev/urandom use the same CSPRNG (different instances) which is periodically reseeded with entropy gathered from the system (hw, interrupt timings, etc.), the only difference being that the /dev/random device blocks if an entropy estimator says that there's "too little entropy". It's not that /dev/random has been "depleted" (which is meaningless given how a CSPRNG works), it's just that some entropy estimation code thinks that it might not be a source of perfect entropy/randomness at a particular time. (This practice is pretty questionable, hence the proposed new syscall.)
- AlyssaRowan 12y agoThis. It'd just be silly to use a slow CSPRNG for that. With this, entropy pool depletion is not really that much of a concern; "urandom reads" from getrandom(2) will have at least one good seed.
- bostik 12y agoAt a guess, those applications routinely require large amounts of mostly random (not CSPRNG random) numbers. This syscall returns data from the kernel's entropy pool, presumably at the speed of /dev/urandom. The recommendation is probably a way to say "please don't abuse, and please don't make the kernel spin".
- deleted 12y ago[deleted]
- mrb 12y agoThe third paragraph in the DESCRIPTION section of the manpage contains a lot of errors: - "then the /dev/raundom pool will be used" -> should be /dev/urandom - "Unlike reading from the /dev/urandom" -> author meant /dev/random - "EGAIN" -> should be EAGAIN - In fact the entire sentence "Unlike reading from /dev/random, [it either blocks or returns EAGAIN]" should be removed. This blocking/EAGAIN behavior is the same regardless if you read from random or urandom.
- acqq 12y ago"Any userspace program which uses this new functionality must make sure that if it is used in early boot, that it will not cause the boot up scripts or other portions of the system startup to hang indefinitely." How can the userspace program "make sure that it doesn't hang indefinitely" if it is started early in the boot process and the call blocks?
- derekp7 12y agoIt can use the expect() system call and timeout / fail after a reasonable period of time if no bits are returned.
- justincormack 12y agoexpect() is not a system call.
- derekp7 12y agoSorry, I meant select(). Don't know where my head was when I typed that.
- nitrogen 12y agoCan you select() a system call (the new proposal) instead of an fd (the old interface)?
- lunixbochs 12y agoYou don't get a file handle to a syscall. You just load up some registers/stack and call a `SYSENTER`, `SYSCALL` or `INT 0x80` instruction. select is itself a separate syscall that takes in file handles or something.
- nitrogen 12y agoYeah, I know, but it wasn't clear if the parent comment was referring to select() on /dev/random, or the new syscall interface.
- kazinator 12y agoThe rationale for this system call is poor. If you're out of descriptors, so that you cannot open another one, then bail loudly! Do not fall back on some ill-conceived code that uses poor quality pseudo-random bits in a situation where such bits must not be used! Also, an descriptor to /dev/urandom can be acquired early and retained for the life of the process. When you need bits, you just read from it. This gets around subsequent chroots and descriptor exhaustion.
- Afforess 12y agoYou missed the 3rd reason for this. Calls to /dev/urandom can not block, so it a script or program requests random bytes before entropy has been set up, it can get back bad random bytes. The new system call getrandoms does block, so early scripts will not get bad entropy data.
- deleted 12y ago[deleted]
- kazinator 12y agoThe newly proposed system call, as implemented in the mailing list patch, provides the functionality of both random and urandom: the behaviors are distinguished by a bitmask. Take a look at the code. If the flag GRND_RANDOM is used, then it uses the random device, otherwise urandom. Independently of this, blocking behavior is requested with GRND_BLOCK. If this is omitted, then the random device bails with errno == EAGAIN if it doesn't have enough entropy, otherwise it blocks. If GRND_BLOCK is omitted with the urandom method (GRND_RANDOM is omitted), then it will bail with -EAGAIN if the urandom device is not initialized; otherwise it just calls urandom_read. With GRND_BLOCK, it will block for urandom to initialize, if necessary. The new system call only blocks when given GRND_BLOCK, and it uses urandom unless given the flag GRND_RANDOM. If it is given GRND_RANDOM, but not GRND_BLOCK, and not enough entropy is available, then the system call with bail with errno == EAGAIN. If there is no GRND_RANDOM then it falls back on urandom_read: that is usually non-blocking.
- Dylan16807 12y ago
- kazinator 12y agoHere is a problem: /dev/random and /dev/urandom have security attributes: ownership and permission. The newly proposed syscall makes no security checks whatsoever to protect the entropy resource: it punches a hole through these perms, effectively.
- syncsynchalt 12y agoWhat's the security case for locking down /dev/random?
- kazinator 12y agoA security case for protecting a source of random bits is that they are important and that cryptographic applications and middleware can malfunction if these bits are not available. A world-readable /dev/random means that anyone can drain out random bits, making them unavailable to these applications. Someone somewhere could be setting up permissions in their Linux-based system based on this type of reasoning. It's a security regression if a character device can be suddenly accessed through a back-channel that ignores permissions.
- seabee 12y agoAFAIK isn't this the kind of thing SELinux can take care of? There needn't be any security regression with this change.
- kzrdude 12y agoand seccomp
- clarry 12y agoIf you don't trust a CSPRNG, then you pretty much might as well turn off all your crypto because you can't trust it. If you can trust a CSPRNG, then you should be able to trust urandom, as long as it's been properly initialized once. It won't drain out. It doesn't run out of bits. One application reading it doesn't make it unavailable for others. The same is true of the syscall.
- AlyssaRowan 12y agoAwesome. Thanks, Theo!
- Rygu 12y agoSlightly off-topic, but I couldn't help but notice as a programmer. I find the coding style of the patch kind of random. The if statements, some of them have braces and some don't. Without a pattern it seems. What is this style called?
- Gracana 12y agoI only see one place where an if statement has curly braces where it doesn't need them. The rest of them only have curly braces if they're necessary.
- Rygu 12y agoOh right, I see the second if statement at block @@ -1533,6 +1544,26 @@ indeed threw me off. I would value consistency over necessity. The else-if at the same block looks weird and the use of new lines could also help the code to be more legible and maintainable. Anyway, sorry went off-topic.
- regd006 12y agoLinux Kernel Coding Style - https://www.kernel.org/doc/Documentation/CodingStyle https://www.kernel.org/doc/Documentation/CodingStyle
- cnst 12y agoProper link that lets you see the discussion: https://lkml.org/lkml/2014/7/17/145 https://lkml.org/lkml/2014/7/17/145
- lvh 12y agoYay! However, a few things that are a bit unfortunate: - It suggests that I use that entropy to seed a PRNG. No. It should be the PRNG. - Fill the buffer with "up to buflen random bytes"? I asked for n bytes. Please give me actually n bytes. If there's a way to get this wrong, people will get it wrong: the BSD socket API does the same thing and at least it has good reason. However, the wording seems to imply that if you use the "urandom" source, it won't do that? - "It should not be used Monte Carlo simulations or for other probabilistic sampling applications.". Doesn't mention why. Sounds like "run out of entropy" FUD :-(
- mackal 12y agoIts more an example of using the wrong tool for the job. You don't use a sludge hammer to hammer a nail in. Monte Carlo simulations don't need CSPRNG.
- gpvos 12y agoSo, does this mean that security issues are causing the end of the Unix "everything is a file" philosophy?
- wtbob 12y ago> The /dev/random pool is limited based on the entropy that can be obtained from environmental noise, so if there is insufficient entropy, the requested number of bytes may not be returned. If there is no entropy available at all, getrandom(2) will either return an error with errno set to EAGAIN, or block if the GRND_BLOCK flags bit is set. Man, that's an ugly interface. So, if there are 8 bits of entropy available and I ask for 16, it will return 8, but if there are none available and I ask for 16 it will block and then return 16. Also, it's not possible to know how much entropy is available. I'd really like to emphasise that: entropy estimation is nonsense. Don't block; seriously, don't block. Just spit out the output of a properly-seeded PRF (e.g. AES in CTR mode).
- gioele 12y ago> Don't block; seriously, don't block. Just spit out the output of a properly-seeded PRF (e.g. AES in CTR mode). /dev/urandom does that and it is the suggested way to get secure random numbers for 99% of the applications.
- wtbob 12y agoNo, /dev/urandom fails the 'properly-seeded' criterion during early boot. The real answer is to just change the interface and be done with it, and to hell with backwards-compatibility, but that'll never happen. The really real answer is to make /dev/random and /dev/urandom the same CSPRNG, seeded as early in boot as possible (and continually refreshed with more entropy, of course), and never blocking thereafter, but that'll never happen either.
- cmhamill 12y agoDoes anyone have any idea why Linux has a distinction between /dev/random and /dev/urandom? Legacy adherence to some defunct interface? Ignorance on the part of kernel devs (seems unlikely)?
- bowyakka 12y agoI think its because linux got there first and designed these interfaces To quote Ted Tso (author of the above patch and the original writer of /dev/random in the first place) The two other interfaces are two character devices /dev/random and * /dev/urandom. /dev/random is suitable for use when very high * quality randomness is desired (for example, for key generation or * one-time pads), as it will only return a maximum of the number of * bits of randomness (as estimated by the random number generator) * contained in the entropy pool. * * The /dev/urandom device does not have this limit, and will return * as many bytes as are requested. As more and more random bytes are * requested without giving time for the entropy pool to recharge, * this will result in random numbers that are merely cryptographically * strong. For many applications, however, this is acceptable.
- deleted 12y ago[deleted]
- ZoFreX 12y ago> If the GRND_RANDOM flags bit is set, then draw from the /dev/random pool instead of /dev/urandom pool. The /dev/random pool is limited based on the entropy that can be obtained from environmental noise, so if there is insufficient entropy, the requested number of bytes may not be returned. If there is no entropy available at all, getrandom(2) will either return an error with errno set to EAGAIN, or block if the GRND_BLOCK flags bit is set. > If the GRND_RANDOM flags bit is not set, then the /dev/raundom pool will be used. Unlike reading from the /dev/urandom, if the urandom pool has not been sufficiently initialized, getrandom(2) will either return an error with errno set to EGAIN, or block if the GRND_BLOCK flags bit is set. Is this complexity necessary? I'm concerned that this will be hard to use properly as there's lots of different behaviours based on the parameters, and different types of failure modes. Security code that is hard to call right or hard to understand tends to get misused, causing security bugs in application code.