Re: [PATCH, RFC] random: introduce getrandom(2) system call
On Wed 2014-07-23 14:10:16, Hannes Frederic Sowa wrote: On Wed, Jul 23, 2014, at 13:52, George Spelvin wrote: I keep wishing for a more general solution. For example, some way to have a spare extra fd that could be accessed with a special O_NOFAIL flag. That would allow any number of library functions to not fail, such as logging from nasty corner cases. But you'd have to provide one per thread, and block non-fatal signals while it was open, so you don't get reentrancy problems. Ick. This overly-specialized system call (and worse yet, a blocking system call that you can't put into a poll() loop) just feels ugly to me. Is it *absolutely* necessary? One point that often came up besides fd exhaustion is missing /dev/u?random device nodes in chroot environments. From the maillist discussion, it seems you sometimes _want_ /dev/random not to be present. For example you want to trace exactly the same path through malware every time. For example, how about simply making getentropy() a library function that aborts if it can't open /dev/urandom? If you're suffering fd exhaustion, you're being DoSed already. Maybe applications want to mitigate fd exhaustion. Dunno. Will we add special read_passwd() syscall that reads just /etc/passwd, to allow uid-name resolution without available FDs? I like the library function suggestion, this should not need a new syscall. And btw -- compatibility with getentropy() is _not_ going to be easy, if they have different blocking / partial read / signals policy. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html -- To unsubscribe from this list: send the line unsubscribe linux-crypto in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH, RFC] random: introduce getrandom(2) system call
Hi, I am wondering if we could improve the design of the system call a bit to prevent programming errors. Right now, EINVAL is returned in case of invalid flags (or in the older version of getrandom() also if buflen is too large), EFAULT if buf is an invalid address and EAGAIN if there is not enough entropy. However, of course no programmer is save against programming errors. Everybody *should* check the return value of syscalls, but sometimes it is forgotten, and theoretically you must be stoned to death for that. Still, we should think about how we could prevent these errors. Here is a list of possible modifications of getrandom() and pros and cons: 1. memset(buf, 0x0, buflen) in case of an error pros: - it is more obvious to the userspace programmer that the content of buffer does *not* contain random bytes cons: - in case even the zero-ed buf is not noticed by the programmer, she/he might end up using a 100% predictable string of random bytes. In contrast if zero-ing the buf is ommitted, you would at least end up using some (not-cryptographically) random bytes from somewhere in RAM. I am aware that this memset() call should theoretically be superfluous but it would only be executed in very rare cases where the programmer misuses getrandom(). 2. int getrandom(void **buf, size_t buflen, unsigned int flags) ^^ If flags, are fine, return a pointer to a buffer of random bytes, otherwise return a pointer to NULL. pros: - it would ensure that an error in a getrandom() call cannot be ignored. cons: - not sure if a syscall should allocate memory in the name of a userspace program - not a very unix-like syscall signature - anytime getrandom() is called, it will allocate a new buffer which might end up in decreased performance (however, getrandom() should not be called multiple times) 3. send a signal to the userland process that (by default) leads to an abnormal termination of the process Essentially an error in getrandom() could be seen as critical as a division by 0. pros: - the userspace programmer is forced to handle this error (otherwise the signal would terminate the program) cons: - adds more complexity to the userspace program that might lead to new programming errors These are three possibilities. Maybe one of you is more creative and can come up with a much better idea. At the moment, I like option 2 the best, because it forces the programmer to deal with these errors, but probably one of you has a good point why this is not a good idea. Handling the NULL pointer would be much easier than using signals (option 3). However, it lead to a syscall signature that is different from, let's say read(), because the syscall itself would allocate its buffer. Again, I am aware that you must always check return values, but programming errors happen. E.g. everybody knows that you cannot trust data that you received via network, yet heartbleed happened. Here we have the chance to eradicate a critical programming error by improving the syscall design and I think we should spend some time thinking about that. Best, Manuel -- To unsubscribe from this list: send the line unsubscribe linux-crypto in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH, RFC] random: introduce getrandom(2) system call
Hi, On Wed, Jul 23, 2014, at 00:59, Theodore Ts'o wrote: But why would you need to use GRND_RANDOM in your scenario, and accept your application potentially getting stalled and stuck in amber for perhaps hours? If you are going to accept your application stalling like that, you can do the pointer arithmatic. It's really not hard, and someone who can't do that, again, shouldn't be allowd anywhere near crypto code in the first place (and if they are, they'll probably be making lots of other, equally fatal if not more so, newbie mistakes). I favored the idea of having a non-failing non-partial-read getrandom syscall. But I am with you if it often causes long stalls that we should stick to the old semantics. Thanks, Hannes -- To unsubscribe from this list: send the line unsubscribe linux-crypto in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH, RFC] random: introduce getrandom(2) system call
I keep wishing for a more general solution. For example, some way to have a spare extra fd that could be accessed with a special O_NOFAIL flag. That would allow any number of library functions to not fail, such as logging from nasty corner cases. But you'd have to provide one per thread, and block non-fatal signals while it was open, so you don't get reentrancy problems. Ick. This overly-specialized system call (and worse yet, a blocking system call that you can't put into a poll() loop) just feels ugly to me. Is it *absolutely* necessary? For example, how about simply making getentropy() a library function that aborts if it can't open /dev/urandom? If you're suffering fd exhaustion, you're being DoSed already. -- To unsubscribe from this list: send the line unsubscribe linux-crypto in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH, RFC] random: introduce getrandom(2) system call
On Wed, Jul 23, 2014, at 13:52, George Spelvin wrote: I keep wishing for a more general solution. For example, some way to have a spare extra fd that could be accessed with a special O_NOFAIL flag. That would allow any number of library functions to not fail, such as logging from nasty corner cases. But you'd have to provide one per thread, and block non-fatal signals while it was open, so you don't get reentrancy problems. Ick. This overly-specialized system call (and worse yet, a blocking system call that you can't put into a poll() loop) just feels ugly to me. Is it *absolutely* necessary? One point that often came up besides fd exhaustion is missing /dev/u?random device nodes in chroot environments. I also thought about a more general interface, like e.g. an opennod(dev_t device, int flags) call but all those ideas ended up being very complex changes besides having design issues. getrandom is simple and solves a real problem. The only problem I see, that we allow access to /dev/random without checking any permission bits like we did on opening /dev/random before and we cannot restrict applications to deplete the whole entropy pool. For example, how about simply making getentropy() a library function that aborts if it can't open /dev/urandom? If you're suffering fd exhaustion, you're being DoSed already. Maybe applications want to mitigate fd exhaustion. Bye, Hannes -- To unsubscribe from this list: send the line unsubscribe linux-crypto in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH, RFC] random: introduce getrandom(2) system call
Hello, On Di, 2014-07-22 at 00:44 -0400, Theodore Ts'o wrote: On Tue, Jul 22, 2014 at 03:02:20AM +0200, Hannes Frederic Sowa wrote: Ted, would it make sense to specifiy a 512 byte upper bound limit for random entropy extraction (I am not yet convinced to do that for urandom) and in case the syscall should block we make sure that we extract the amount of bytes the user requested? On some systems, it's still possible that with a large /dev/random extraction, you could end up blocking for hours. So either the getrandom(2) syscall needs to be uninterruptible, which has one set of problems (and not just the user typing ^C, but also things like being able to process alarms, which is highly problematic indeed), or you need to allow it to be interruptible by a signal, in which case userspace needs to check the error return for things like EINTR anyway. And if you have to check the error return, you might as well check the number of bytes returned. I think a lot of checks are of the type if (getrandom() 0), so this actually was the kind of programming errors I wanted to guard against. Also, on some systems it is very likely that we return a short write to user space, so it prevents this very common situation. Even if one would like to extract 64 bytes randomness, one would often need two calls to getrandom() on my virtualized systems. Would be great to know that in blocking mode, either I get a -1 or the buffer is always filled and I won't need to do pointer arithmetic to fill the rest of the buffer. I still think it is a good idea even without caring about the signal interruptions. Yes, one could in theory set up a new variant of uninterruptible signals that only exited if the signal caused the process to exit, and otherwise, forced a system call restart even if SA_INTERRUPTIBLE was not set in sigalarim, but that's add *way* more complexity than this deserves. I don't want to do that. It is totally ok if we return -1 and set errno to EINTR in case of pending signals. Basically, I view /dev/random as an advanced call, and someone who uses it should know what they are doing. It's not the default for a reason. I agree, but I still think this would make the interface a bit more friendly to use. Thanks, Hannes -- To unsubscribe from this list: send the line unsubscribe linux-crypto in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH, RFC] random: introduce getrandom(2) system call
On Tue, Jul 22, 2014 at 11:49:52AM +0200, Hannes Frederic Sowa wrote: I think a lot of checks are of the type if (getrandom() 0), so this actually was the kind of programming errors I wanted to guard against. Also, on some systems it is very likely that we return a short write to user space, so it prevents this very common situation. Even if one would like to extract 64 bytes randomness, one would often need two calls to getrandom() on my virtualized systems. Would be great to know that in blocking mode, either I get a -1 or the buffer is always filled and I won't need to do pointer arithmetic to fill the rest of the buffer. But why would you need to use GRND_RANDOM in your scenario, and accept your application potentially getting stalled and stuck in amber for perhaps hours? If you are going to accept your application stalling like that, you can do the pointer arithmatic. It's really not hard, and someone who can't do that, again, shouldn't be allowd anywhere near crypto code in the first place (and if they are, they'll probably be making lots of other, equally fatal if not more so, newbie mistakes). - Ted -- To unsubscribe from this list: send the line unsubscribe linux-crypto in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH, RFC] random: introduce getrandom(2) system call
On Thu, Jul 17, 2014 at 05:18:15AM -0400, Theodore Ts'o wrote:
SYNOPSIS
#include linux/random.h
int getrandom(void *buf, size_t buflen, unsigned int flags);
DESCRIPTION
The system call getrandom() fills the buffer pointed to by buf
with up to buflen random bytes which can be used to seed user
space random number generators (i.e., DRBG's) or for other
cryptographic processes. It should not be used Monte Carlo
simulations or for other probabilistic sampling applications.
Aside from poor performance for the offending application, will anything
actually break if an application ignores this warning and makes heavy
use of getrandom(2)? It would be helpful if the documentation made this
clearer, rather than just saying, don't do that.
As the developer of a userspace crypto library, I can't always prevent
downstream developers from doing silly things, and many developers
simply don't understand different kinds of random numbers, so I prefer
to tell them to just use the kernel CSPRNG by default, and to ask for
help once they run into performance problems. It's not ideal, but it's
safer than the alternative.[1]
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.
RETURN VALUE
On success, the number of bytes that was returned is returned.
On error, -1 is returned, and errno is set appropriately
Hm. Is it correct that, in blocking mode, the call is guaranteed either
to return -EINVAL immediately, or to block until the buffer is
*completely* populated with buflen bytes? If so, I think a few small
changes could make this a really nice interface to work with:
* Use blocking mode by default.
* Add a new flag called GRND_PARTIAL (replacing GRND_BLOCK), which
indicates that the caller is prepared to handle a partial/incomplete
result.
* On success with GRND_PARTIAL, return the number of bytes that were
written into buf. (Or -EAGAIN, as is currently done.)
* If GRND_PARTIAL is *not* set, just return 0 on success. (This avoids
all signed-unsigned confusion when buflen INT_MAX.)
With those changes, it would be trivial for a userspace library to
implement a reliable RNG interface as recommended in [2] or [3]:
/*
* memzap(3)
*
* Fills the buffer pointed to by buf with exactly buflen random bytes
* suitable for cryptographic purposes. Nothing is returned.
*
* This function is thread-safe, and is safe to call from inside a
* signal handler.
*
* It blocks if the kernel random number generator is not yet fully
* initialized (e.g. early in the boot process), and it may trigger
* abort(3) if invoked on an old kernel version that does not support
* the getrandom(2) system call.
*/
void memzap(void *buf, size_t buflen)
{
int ret;
ret = getrandom(buf, buflen, 0);
if (ret != 0) {
perror(getrandom(2) failed);
abort();
}
}
Best,
- Dwayne
P.S. If I had my way, I would also drop GRND_RANDOM. Most software
won't use it, there's no legacy installed base, and no developer who
still wants that behavior can legitimately claim to care about RNG
availability guarantees, IMHO. Anyone who really wants the old
/dev/random behavior can always just continue to use the existing
character device. I don't really care enough to put up a fight about
it, though, as long as it doesn't affect the quality of the
non-GRND_RANDOM interface.
[1] On more than one occasion, I've seen developers use Python's
standard random module to generate IVs. I mean, why not? IVs are
public, right?
[2] http://cr.yp.to/highspeed/coolnacl-20120725.pdf
[3]
https://groups.google.com/forum/#!msg/randomness-generation/4opmDHA6_3w/__TyKhbnNWsJ
--
Dwayne C. Litzenberger dl...@dlitz.net
OpenPGP: 19E1 1FE8 B3CF F273 ED17 4A24 928C EC13 39C2 5CF7
pgpApJX2wIboT.pgp
Description: PGP signature
Re: [PATCH, RFC] random: introduce getrandom(2) system call
On Sun, Jul 20, 2014 at 05:25:40PM -0700, Dwayne Litzenberger wrote: This could still return predictable bytes during early boot, though, right? Read the suggetsed man page; especially, the version of the man page in the commit description -v4 version of the patch. getrandom(2) is a new interface, so I can afford do things differently from redaing from /dev/urandom. Specifically, it will block until it is fully initialized, and in GRND_NONBLOCK mode, it will return EAGAIN. There have been some people kvetching and whining that this is less convenient for seeding srand(3), but for non-crypto uses, using getpid() and time() to seed random(3) or rand(3) is just fine, and if they really want, they can open /dev/urandom. The system call getrandom() fills the buffer pointed to by buf with up to buflen random bytes which can be used to seed user space random number generators (i.e., DRBG's) or for other cryptographic processes. It should not be used Monte Carlo simulations or for other probabilistic sampling applications. Aside from poor performance for the offending application, will anything actually break if an application ignores this warning and makes heavy use of getrandom(2)? It will be slow, and then the graduate student will whine and complain and send a bug report. It will cause urandom to pull more heavily on entropy, and if that means that you are using some kind of hardware random generator on a laptop, such as tpm-rng, you will burn more battery, but no, it will not break. This is why the man page says SHOULD not, and not MUST not. :-) As the developer of a userspace crypto library, I can't always prevent downstream developers from doing silly things, and many developers simply don't understand different kinds of random numbers, so I prefer to tell them to just use the kernel CSPRNG by default, and to ask for help once they run into performance problems. It's not ideal, but it's safer than the alternative.[1] Yes, but the point is that Monte Carlo simulations don't need any kind crypto guarantees. Hm. Is it correct that, in blocking mode, the call is guaranteed either to return -EINVAL immediately, or to block until the buffer is *completely* populated with buflen bytes? If so, I think a few small changes could make this a really nice interface to work with: * Use blocking mode by default. Read the -v4 version of the patch. Blocking is now the default. * Add a new flag called GRND_PARTIAL (replacing GRND_BLOCK), which indicates that the caller is prepared to handle a partial/incomplete result. This is not needed if you are using the preferred use of flags == 0, and are extracting a sane amount of entropy. For values of buflen 256 bytes, once urandom pool is initialized, getrandom(buf, buflen, 0) will not block and will always return the amount of entropy that you asked for. But if the user asks for INT_MAX bytes, getrandom(2) must be interruptible, or else you will end up burning CPU time for a long, LONG, LONG time. The choice was to either pick some arbitrarily limit, such as 256, and then return EIO, which is what OpenBSD did. I decided to simply allow getrandom(2) to be interruptible if buflen 256. Similarly, if you use GRND_RANDOM, you are also implicitly agreeing for what you are calling GRND_PARTIAL semantics, because otherwise, you could end up blocking for a very long time, with no way to interrupt a buggy program. I'd much rather keep things simple, and not add too many extra flags, especially when certain combination of flags result in a really unfriendly / insane result. * If GRND_PARTIAL is *not* set, just return 0 on success. (This avoids all signed-unsigned confusion when buflen INT_MAX.) We simply cap any requests for buflen INT_MAX, and in practice, it would take so long to generate the requested number of bytes that the user would want to interrupt the process anyway. I considered adding a printk to shame any application writer that tried to ask for more than 256 bytes, but ultimately decided that was a bit over the top. But in any case, any request anywhere near INT_MAX bytes is really not anything I'm concerned about. If we do start seeing evidence for that, I might reconsider and add some kind of Warning! The author of [current-comm] is asking for insane amounts of entropy printk. With those changes, it would be trivial for a userspace library to implement a reliable RNG interface as recommended in [2] or [3]: The userspace library should ideally be integrted into glibc, so it is fork- and thread- aware, and it should use a proper CRNG, much like OpenBSD's arcrandom(3). There's been a proposal submitted to the Austin Group for future standardization in Posix, and I'm all in favor of something like that. P.S. If I had my way, I would also drop GRND_RANDOM. Most software won't use it, there's no legacy installed base, and no developer who still wants that behavior can
Re: [PATCH, RFC] random: introduce getrandom(2) system call
I don't like partial reads/writes and think that a lot of people get them wrong, because they often only check for negative return values. The v1 patch, which did it right IMHO, didn't do partial reads in the case we're talking about: + if (count 256) + return -EINVAL; In case of urandom extraction, I wouldn't actually limit the number of bytes. A lot of applications I have seen already extract more than 128 out of urandom (not for seeding a prng but just to mess around with some memory). I don't see a reason why getrandom shouldn't be used for that. It just adds one more thing to look out for if using getrandom() in urandom mode, especially during porting an application over to this new interface. Again, I disagree. If it's just messing around code, use /dev/urandom. It's more portable and you don't care about the fd exhaustion attacks. If it's actual code to be used in anger, fix it to not abuse /dev/urandom. You're right that a quick hack might be broken on purpose, but without exception, *all* code that I have seen which reads 64 or more bytes from /dev/*random is broken, and highlighting the brokenness is a highly desirable thing. The sole and exclusive reason for this syscall to exist at all is to solve a security problem. Supporting broken security code does no favors to anyone. -- To unsubscribe from this list: send the line unsubscribe linux-crypto in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH, RFC] random: introduce getrandom(2) system call
On Mo, 2014-07-21 at 07:21 -0400, George Spelvin wrote: I don't like partial reads/writes and think that a lot of people get them wrong, because they often only check for negative return values. The v1 patch, which did it right IMHO, didn't do partial reads in the case we're talking about: + if (count 256) + return -EINVAL; I checked and unfortunately it does not; 256 bytes is way too large to guarantee non-existence of partial reads. On a typical older system without rdrand/rdseed you would have to limit the amount of bytes to extract to about 32. That's way too low. That said, the 512 bytes check only in case of extracting bytes from blocking pool would serve no purpose. In case of urandom extraction, I wouldn't actually limit the number of bytes. A lot of applications I have seen already extract more than 128 out of urandom (not for seeding a prng but just to mess around with some memory). I don't see a reason why getrandom shouldn't be used for that. It just adds one more thing to look out for if using getrandom() in urandom mode, especially during porting an application over to this new interface. Again, I disagree. If it's just messing around code, use /dev/urandom. It's more portable and you don't care about the fd exhaustion attacks. If it's actual code to be used in anger, fix it to not abuse /dev/urandom. You're right that a quick hack might be broken on purpose, but without exception, *all* code that I have seen which reads 64 or more bytes from /dev/*random is broken, and highlighting the brokenness is a highly desirable thing. The sole and exclusive reason for this syscall to exist at all is to solve a security problem. Supporting broken security code does no favors to anyone. Then let's agree to disagree. :) I think it is dangerous if application will get ported to this new interface without checking size limitations and will only notice it after the applications will be rolled out (if at all). Bye, Hannes -- To unsubscribe from this list: send the line unsubscribe linux-crypto in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH, RFC] random: introduce getrandom(2) system call
On Mo, 2014-07-21 at 17:27 +0200, Hannes Frederic Sowa wrote:
On Mo, 2014-07-21 at 07:21 -0400, George Spelvin wrote:
I don't like partial reads/writes and think that a lot of people get
them wrong, because they often only check for negative return values.
The v1 patch, which did it right IMHO, didn't do partial reads in the
case we're talking about:
+ if (count 256)
+ return -EINVAL;
I checked and unfortunately it does not; 256 bytes is way too large to
guarantee non-existence of partial reads. On a typical older system
without rdrand/rdseed you would have to limit the amount of bytes to
extract to about 32. That's way too low. That said, the 512 bytes check
only in case of extracting bytes from blocking pool would serve no
purpose.
Ted, would it make sense to specifiy a 512 byte upper bound limit for
random entropy extraction (I am not yet convinced to do that for
urandom) and in case the syscall should block we make sure that we
extract the amount of bytes the user requested?
Having a quick look maybe something like this? Only compile tested and
maybe can still be simplified. It guarantees we don't do a partial write
to user space for sub 512 bytes requests.
diff --git a/drivers/char/random.c b/drivers/char/random.c
index 2721543..c0db6f5 100644
--- a/drivers/char/random.c
+++ b/drivers/char/random.c
@@ -1345,8 +1345,14 @@ static int arch_random_refill(void)
return n;
}
+enum blocking_mode {
+ NONBLOCKING,
+ SYSCALL_BLOCK,
+ DEV_RANDOM_BLOCK
+};
+
static ssize_t
-_random_read(int nonblock, char __user *buf, size_t nbytes)
+_random_read(enum blocking_mode mode, char __user *buf, size_t nbytes)
{
ssize_t n;
@@ -1361,7 +1367,7 @@ _random_read(int nonblock, char __user *buf, size_t
nbytes)
trace_random_read(n*8, (nbytes-n)*8,
ENTROPY_BITS(blocking_pool),
ENTROPY_BITS(input_pool));
- if (n 0)
+ if (mode != SYSCALL_BLOCK n 0)
return n;
/* Pool is (near) empty. Maybe wait and retry. */
@@ -1370,7 +1376,7 @@ _random_read(int nonblock, char __user *buf, size_t
nbytes)
if (arch_random_refill())
continue;
- if (nonblock)
+ if (mode == NONBLOCKING)
return -EAGAIN;
wait_event_interruptible(random_read_wait,
@@ -1384,7 +1390,8 @@ _random_read(int nonblock, char __user *buf, size_t
nbytes)
static ssize_t
random_read(struct file *file, char __user *buf, size_t nbytes, loff_t *ppos)
{
- return _random_read(file-f_flags O_NONBLOCK, buf, nbytes);
+ return _random_read(file-f_flags O_NONBLOCK ? NONBLOCKING :
+ DEV_RANDOM_BLOCK, buf, nbytes);
}
static ssize_t
@@ -1534,8 +1541,6 @@ const struct file_operations urandom_fops = {
SYSCALL_DEFINE3(getrandom, char __user *, buf, size_t, count,
unsigned int, flags)
{
- int r;
-
if (flags ~(GRND_NONBLOCK|GRND_RANDOM))
return -EINVAL;
@@ -1543,7 +1548,8 @@ SYSCALL_DEFINE3(getrandom, char __user *, buf, size_t,
count,
count = INT_MAX;
if (flags GRND_RANDOM)
- return _random_read(flags GRND_NONBLOCK, buf, count);
+ return _random_read(flags GRND_NONBLOCK ? NONBLOCKING :
+ SYSCALL_BLOCK, buf, count);
if (unlikely(nonblocking_pool.initialized == 0)) {
if (flags GRND_NONBLOCK)
Bye,
Hannes
--
To unsubscribe from this list: send the line unsubscribe linux-crypto in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH, RFC] random: introduce getrandom(2) system call
On Tue, Jul 22, 2014 at 03:02:20AM +0200, Hannes Frederic Sowa wrote: Ted, would it make sense to specifiy a 512 byte upper bound limit for random entropy extraction (I am not yet convinced to do that for urandom) and in case the syscall should block we make sure that we extract the amount of bytes the user requested? On some systems, it's still possible that with a large /dev/random extraction, you could end up blocking for hours. So either the getrandom(2) syscall needs to be uninterruptible, which has one set of problems (and not just the user typing ^C, but also things like being able to process alarms, which is highly problematic indeed), or you need to allow it to be interruptible by a signal, in which case userspace needs to check the error return for things like EINTR anyway. And if you have to check the error return, you might as well check the number of bytes returned. Yes, one could in theory set up a new variant of uninterruptible signals that only exited if the signal caused the process to exit, and otherwise, forced a system call restart even if SA_INTERRUPTIBLE was not set in sigalarim, but that's add *way* more complexity than this deserves. Basically, I view /dev/random as an advanced call, and someone who uses it should know what they are doing. It's not the default for a reason. - Ted -- To unsubscribe from this list: send the line unsubscribe linux-crypto in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH, RFC] random: introduce getrandom(2) system call
Theodore Ts'o ty...@mit.edu writes: #undef __NR_syscalls -#define __NR_syscalls 277 +#define __NR_syscalls 278 You need to add the syscall to kernel/sys_ni.c too, otherwise it will be impossible to build without random device. -Andi -- a...@linux.intel.com -- Speaking for myself only -- To unsubscribe from this list: send the line unsubscribe linux-crypto in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH, RFC] random: introduce getrandom(2) system call
One basic question... why limit this to /dev/random? If we're trying to avoid fd exhaustion attacks, wouldn't an atomically read a file into a buffer system call (that could be used on /dev/urandom, or /etc/hostname, or /proc/foo, or...) be more useful? E.g. ssize_t readat(int dirfd, char const *path, struct stat *st, char *buf, size_t len, int flags); It's basically equivalent to openat(), optional fstat() (if st is non-NULL), read(), close(), but it doesn't allocate an fd number. Is it necessary to have a system call just for entropy? If you want a urandom that blocks until seeded, you can always create another device node for the purpose. The main argument I can see for putting in a limit is to encourage the proper use of the interface. In practice, anything larger than 128 probably means the interface is getting misused, either due to a bug or some other kind of oversight. Agreed. Even 1024 bits is excessive. 32 bytes is the real maximum that people should be asking for with current primitives, so an interface limitation to 64 is quite defensible. (But 128 isn't *wildly* excessive.) If you do stick with a random-specific call, specifying the entropy in bits (with some specified convention for the last fractional byte) is anothet interesting idea. Perhaps too prone to bugs, though. (People thinking it's bytes and producing low-entropy keys.) -- To unsubscribe from this list: send the line unsubscribe linux-crypto in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH, RFC] random: introduce getrandom(2) system call
In the end people would just recall getentropy in a loop and fetch 256 bytes each time. I don't think the artificial limit does make any sense. I agree that this allows a potential misuse of the interface, but doesn't a warning in dmesg suffice? It makes their code not work, so they can are forced to think about fixing it before adding the obvious workaround. It also makes it easier to port applications from open(/dev/*random), read(...) to getentropy() by reusing the same limits. But such an application *is broken*. Making it easier to port is an anti-goal. The goal is to make it enough of a hassle that people will *fix* their code. There's a *reason* that the /dev/random man page explicitly tells people not to trust software that reads more than 32 bytes at a time from /dev/random: While some safety margin above that minimum is reasonable, as a guard against flaws in the CPRNG algorithm, no cryptographic primitive avail- able today can hope to promise more than 256 bits of security, so if any program reads more than 256 bits (32 bytes) from the kernel random pool per invocation, or per reasonable reseed interval (not less than one minute), that should be taken as a sign that its cryptography is *not* skillfully implemented. (not skilfuly implemented was the phrase chosen after some discussion to convey either a quick hack or something you dhouldn't trust.) To expand on what I said in my mail to Ted, 256 is too high. I'd go with OpenBSD's 128 bytes or even drop it to 64. -- To unsubscribe from this list: send the line unsubscribe linux-crypto in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH, RFC] random: introduce getrandom(2) system call
On Sun, Jul 20, 2014 at 08:50:06AM -0700, Andi Kleen wrote: Theodore Ts'o ty...@mit.edu writes: #undef __NR_syscalls -#define __NR_syscalls 277 +#define __NR_syscalls 278 You need to add the syscall to kernel/sys_ni.c too, otherwise it will be impossible to build without random device. The random device is not optional; it is alaways guaranteed to be present. From drivers/char/Makefile: obj-y += mem.o random.o Cheers, - Ted -- To unsubscribe from this list: send the line unsubscribe linux-crypto in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH, RFC] random: introduce getrandom(2) system call
On Sun, Jul 20, 2014 at 12:26:22PM -0400, George Spelvin wrote: One basic question... why limit this to /dev/random? If we're trying to avoid fd exhaustion attacks, wouldn't an atomically read a file into a buffer system call (that could be used on /dev/urandom, or /etc/hostname, or /proc/foo, or...) be more useful? E.g. ssize_t readat(int dirfd, char const *path, struct stat *st, char *buf, size_t len, int flags); It's basically equivalent to openat(), optional fstat() (if st is non-NULL), read(), close(), but it doesn't allocate an fd number. Is it necessary to have a system call just for entropy? If you want a urandom that blocks until seeded, you can always create another device node for the purpose. I'd really rather not go down this path. Your readat(2) proposal is interesting, but it adds a whole lot of complications. For example, just simply booting a new kernel doesn't guarantee that a new device node for blocks until seeded will exist. So that means a lot of applications will just either continue to use /dev/urandom, or have to put in fallback code to first try the new device name, and then fall back to /dev/urandom. (And of course, they have to deal with what to do if /dev/urandom doesn't exist --- which presumably would be raise(SIGKILL), but we're now talking about a number of lines of codes that application writers would have to get right.) Readat(2) would also have to get linked into auditing, and LSM, and honestly, it's a lot more work that I'm not all that interested in doing and trying to get right. If you do stick with a random-specific call, specifying the entropy in bits (with some specified convention for the last fractional byte) is anothet interesting idea. Perhaps too prone to bugs, though. (People thinking it's bytes and producing low-entropy keys.) Definitely not worth the complexity. - Ted -- To unsubscribe from this list: send the line unsubscribe linux-crypto in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH, RFC] random: introduce getrandom(2) system call
Theodore Ts'o ty...@mit.edu writes: ERRORS EINVAL The buflen value was invalid. Also on unknown flags? Without that it would be impossible to probe for implemented flags. Andreas. -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 And now for something completely different. -- To unsubscribe from this list: send the line unsubscribe linux-crypto in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH, RFC] random: introduce getrandom(2) system call
On Sun, Jul 20, 2014 at 07:27:42PM +0200, Andreas Schwab wrote: Theodore Ts'o ty...@mit.edu writes: ERRORS EINVAL The buflen value was invalid. Also on unknown flags? Without that it would be impossible to probe for implemented flags. We removed the cap on the buflen size (although if someone gives something insanely large, it can get capped), so EINVAL will only happen for unknown flags. I'll fix the suggested man page. - Ted P.S. The reason why OpenBSD had a very strong opinion about returning EIO for buflen greater than 256 bytes was they really wanted to pound it into application writers than if they were trying to fetch more than 256 bytes, they were probably Doing Something Wrong, and they decided EIO was less subtle that EINVAL -- To unsubscribe from this list: send the line unsubscribe linux-crypto in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH, RFC] random: introduce getrandom(2) system call
On So, 2014-07-20 at 13:03 -0400, George Spelvin wrote: In the end people would just recall getentropy in a loop and fetch 256 bytes each time. I don't think the artificial limit does make any sense. I agree that this allows a potential misuse of the interface, but doesn't a warning in dmesg suffice? It makes their code not work, so they can are forced to think about fixing it before adding the obvious workaround. It also makes it easier to port applications from open(/dev/*random), read(...) to getentropy() by reusing the same limits. But such an application *is broken*. Making it easier to port is an anti-goal. The goal is to make it enough of a hassle that people will *fix* their code. There's a *reason* that the /dev/random man page explicitly tells people not to trust software that reads more than 32 bytes at a time from /dev/random: While some safety margin above that minimum is reasonable, as a guard against flaws in the CPRNG algorithm, no cryptographic primitive avail- able today can hope to promise more than 256 bits of security, so if any program reads more than 256 bits (32 bytes) from the kernel random pool per invocation, or per reasonable reseed interval (not less than one minute), that should be taken as a sign that its cryptography is *not* skillfully implemented. (not skilfuly implemented was the phrase chosen after some discussion to convey either a quick hack or something you dhouldn't trust.) To expand on what I said in my mail to Ted, 256 is too high. I'd go with OpenBSD's 128 bytes or even drop it to 64. I don't like partial reads/writes and think that a lot of people get them wrong, because they often only check for negative return values. I thought about the following check (as replacement for the old check): /* we will always generate a partial buffer fill */ if (flags GRND_RANDOM count 512) return -EINVAL; We could also be more conservative and return -EINVAL in case a stray write happened if one tried to extract less than 512 by checking the return values of random_read(), but somehow this sounds dangerous to me. In case of urandom extraction, I wouldn't actually limit the number of bytes. A lot of applications I have seen already extract more than 128 out of urandom (not for seeding a prng but just to mess around with some memory). I don't see a reason why getrandom shouldn't be used for that. It just adds one more thing to look out for if using getrandom() in urandom mode, especially during porting an application over to this new interface. Bye, Hannes -- To unsubscribe from this list: send the line unsubscribe linux-crypto in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH, RFC] random: introduce getrandom(2) system call
On Thu, Jul 17, 2014 at 01:01:16PM -0400, Theodore Ts'o wrote:
The getrandom(2) system call is a superset of getentropy(2). When we
add the support for this into glibc, it won't be terribly difficult
nor annoying to drop the following in alongside the standard support
needed for any new system call:
int getentropy(void *buf, size_t buflen)
{
int ret;
ret = getentropy(buf, buflen, 0);
return (ret 0) ? 0 : ret;
}
The reason for the additional flags is that I'm trying to solve more
problems than just getentropy()'s raison d'etre. The discussion of
this is in the commit description; let me know if there bits that I
could make clearer.
This could still return predictable bytes during early boot, though,
right?
--
Dwayne C. Litzenberger dl...@dlitz.net
OpenPGP: 19E1 1FE8 B3CF F273 ED17 4A24 928C EC13 39C2 5CF7
--
To unsubscribe from this list: send the line unsubscribe linux-crypto in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH, RFC] random: introduce getrandom(2) system call
The getrandom(2) system call was requested by the LibreSSL Portable developers. It is analoguous to the getentropy(2) system call in OpenBSD. The rationale of this system call is to provide resiliance against file descriptor exhaustion attacks, where the attacker consumes all available file descriptors, forcing the use of the fallback code where /dev/[u]random is not available. Since the fallback code is often not well-tested, it is better to eliminate this potential failure mode entirely. The other feature provided by this new system call is the ability to request randomness from the /dev/urandom entropy pool, but to block until at least 128 bits of entropy has been accumulated in the /dev/urandom entropy pool. Historically, the emphasis in the /dev/urandom development has been to ensure that urandom pool is initialized as quickly as possible after system boot, and preferably before the init scripts start execution. This is because changing /dev/urandom reads to block represents an interface change that could potentially break userspace which is not acceptable. In practice, on most x86 desktop and server systems, in general the entropy pool can be initialized before it is needed (and in modern kernels, we will printk a warning message if not). However, on an embedded system, this may not be hte case. And so with a new interface, we can provide this requested functionality of blocking until the urandom pool has been initialized. 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. SYNOPSIS #include linux/random.h int getrandom(void *buf, size_t buflen, unsigned int flags); DESCRIPTION The system call getrandom() fills the buffer pointed to by buf with up to buflen random bytes which can be used to seed user space random number generators (i.e., DRBG's) or for other cryptographic processes. It should not be used Monte Carlo simulations or for other probabilistic sampling applications. 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. RETURN VALUE On success, the number of bytes that was returned is returned. On error, -1 is returned, and errno is set appropriately ERRORS EINVAL The buflen value was invalid. EFAULT buf is outside your accessible address space. EAGAIN The requested entropy was not available, and the getentropy(2) would have blocked if GRND_BLOCK flag was set. Signed-off-by: Theodore Ts'o ty...@mit.edu --- arch/x86/syscalls/syscall_32.tbl | 1 + arch/x86/syscalls/syscall_64.tbl | 1 + drivers/char/random.c | 35 +-- include/linux/syscalls.h | 3 +++ include/uapi/asm-generic/unistd.h | 4 +++- include/uapi/linux/random.h | 9 + 6 files changed, 50 insertions(+), 3 deletions(-) diff --git a/arch/x86/syscalls/syscall_32.tbl b/arch/x86/syscalls/syscall_32.tbl index d6b8679..f484e39 100644 --- a/arch/x86/syscalls/syscall_32.tbl +++ b/arch/x86/syscalls/syscall_32.tbl @@ -360,3 +360,4 @@ 351i386sched_setattr sys_sched_setattr 352i386sched_getattr sys_sched_getattr 353i386renameat2 sys_renameat2 +354i386getrandom sys_getrandom diff --git a/arch/x86/syscalls/syscall_64.tbl b/arch/x86/syscalls/syscall_64.tbl index ec255a1..6705032 100644 --- a/arch/x86/syscalls/syscall_64.tbl +++ b/arch/x86/syscalls/syscall_64.tbl @@ -323,6 +323,7 @@ 314common sched_setattr sys_sched_setattr 315common sched_getattr sys_sched_getattr 316common renameat2 sys_renameat2 +317common getrandom sys_getrandom # # x32-specific system call numbers start at 512 to avoid cache impact diff --git a/drivers/char/random.c b/drivers/char/random.c index aa22fe5..76a56f6 100644 --- a/drivers/char/random.c +++ b/drivers/char/random.c @@ -258,6 +258,8 @@ #include linux/kmemcheck.h #include
Re: [PATCH, RFC] random: introduce getrandom(2) system call
On Do, 2014-07-17 at 05:18 -0400, Theodore Ts'o wrote:
SYNOPSIS
#include linux/random.h
int getrandom(void *buf, size_t buflen, unsigned int flags);
Cool, I think the interface is sane.
Btw. couldn't libressl etc. fall back to binary_sysctl
kernel.random.uuid and seed with that as a last resort? We have it
available for few more years.
+SYSCALL_DEFINE3(getrandom, char __user *, buf, size_t, count,
+ unsigned int, flags)
+{
+ int r;
+
+ if (count 256)
+ return -EINVAL;
+
Why this arbitrary limitation? Couldn't we just check for SSIZE_MAX
or to be more conservative to INT_MAX?
+ if (flags GRND_RANDOM) {
+ return _random_read(!(flags GRND_BLOCK), buf, count);
+ }
+ if (flags GRND_BLOCK) {
+ r = wait_for_completion_interruptible(urandom_initialized);
+ if (r)
+ return r;
+ } else if (!completion_done(urandom_initialized))
+ return -EAGAIN;
+ return urandom_read(NULL, buf, count, NULL);
+}
+
Great, thanks Ted,
Hannes
--
To unsubscribe from this list: send the line unsubscribe linux-crypto in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH, RFC] random: introduce getrandom(2) system call
On 2014-07-17 at 11:18:15 +0200, Theodore Ts'o ty...@mit.edu wrote: [...] +/* + * Flags for getrandom(2) + * + * GAND_BLOCKAllow getrandom(2) to block + * GAND_RANDOM Use the /dev/random pool instead of /dev/urandom + */ Very minor nitpick: These should probably read GRND_BLOCK/GRND_RANDOM as well, no? +#define GRND_BLOCK 0x0001 +#define GRND_RANDOM 0x0002 + #endif /* _UAPI_LINUX_RANDOM_H */ -- 2.0.0 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ -- To unsubscribe from this list: send the line unsubscribe linux-crypto in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH, RFC] random: introduce getrandom(2) system call
On Thu, Jul 17, 2014 at 12:57:07PM +0200, Hannes Frederic Sowa wrote: Btw. couldn't libressl etc. fall back to binary_sysctl kernel.random.uuid and seed with that as a last resort? We have it available for few more years. Yes, they could. But trying to avoid more uses of binary_sysctl seems to be a good thing, I think. The other thing is that is that this interface provides is the ability to block until the entropy pool is initialized, which isn't a big deal for x86 systems, but might be useful as a gentle forcing function to force ARM systems to figure out good ways of making sure the entropy pools are initialized (i.e., by actually providing !@#!@ cycle counter) without breaking userspace compatibility --- since this is a new interface. + if (count 256) + return -EINVAL; + Why this arbitrary limitation? Couldn't we just check for SSIZE_MAX or to be more conservative to INT_MAX? I'm not wedded to this limitation. OpenBSD's getentropy(2) has an architected arbitrary limit of 128 bytes. I haven't made a final decision if the right answer is to hard code some value, or make this limit be configurable, or remote the limit entirely (which in practice would be SSIZE_MAX or INT_MAX). The main argument I can see for putting in a limit is to encourage the proper use of the interface. In practice, anything larger than 128 probably means the interface is getting misused, either due to a bug or some other kind of oversight. For example, when I started instrumenting /dev/urandom, I caught Google Chrome pulling 4k out of /dev/urandom --- twice --- at startup time. It turns out it was the fault of the NSS library, which was using fopen() to access /dev/urandom. (Sigh.) - Ted -- To unsubscribe from this list: send the line unsubscribe linux-crypto in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH, RFC] random: introduce getrandom(2) system call
On Thu, Jul 17, 2014 at 02:09:49PM +0200, Tobias Klauser wrote: +/* + * Flags for getrandom(2) + * + * GAND_BLOCK Allow getrandom(2) to block + * GAND_RANDOM Use the /dev/random pool instead of /dev/urandom + */ Very minor nitpick: These should probably read GRND_BLOCK/GRND_RANDOM as well, no? Thanks, typo. I'll get this fixed up. - Ted -- To unsubscribe from this list: send the line unsubscribe linux-crypto in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH, RFC] random: introduce getrandom(2) system call
On Do, 2014-07-17 at 08:52 -0400, Theodore Ts'o wrote: On Thu, Jul 17, 2014 at 12:57:07PM +0200, Hannes Frederic Sowa wrote: Btw. couldn't libressl etc. fall back to binary_sysctl kernel.random.uuid and seed with that as a last resort? We have it available for few more years. Yes, they could. But trying to avoid more uses of binary_sysctl seems to be a good thing, I think. The other thing is that is that this interface provides is the ability to block until the entropy pool is initialized, which isn't a big deal for x86 systems, but might be useful as a gentle forcing function to force ARM systems to figure out good ways of making sure the entropy pools are initialized (i.e., by actually providing !@#!@ cycle counter) without breaking userspace compatibility --- since this is a new interface. I am not questioning this new interface - I like it - just wanted to mention there is already a safe fallback for LibreSSL in the way they already seem to do it in OpenBSD (via sysctl). + if (count 256) + return -EINVAL; + Why this arbitrary limitation? Couldn't we just check for SSIZE_MAX or to be more conservative to INT_MAX? I'm not wedded to this limitation. OpenBSD's getentropy(2) has an architected arbitrary limit of 128 bytes. I haven't made a final decision if the right answer is to hard code some value, or make this limit be configurable, or remote the limit entirely (which in practice would be SSIZE_MAX or INT_MAX). The main argument I can see for putting in a limit is to encourage the proper use of the interface. In practice, anything larger than 128 probably means the interface is getting misused, either due to a bug or some other kind of oversight. For example, when I started instrumenting /dev/urandom, I caught Google Chrome pulling 4k out of /dev/urandom --- twice --- at startup time. It turns out it was the fault of the NSS library, which was using fopen() to access /dev/urandom. (Sigh.) In the end people would just recall getentropy in a loop and fetch 256 bytes each time. I don't think the artificial limit does make any sense. I agree that this allows a potential misuse of the interface, but doesn't a warning in dmesg suffice? It also makes it easier to port applications from open(/dev/*random), read(...) to getentropy() by reusing the same limits. I would vote for warning (at about 256 bytes) + no limit. Thanks, Hannes -- To unsubscribe from this list: send the line unsubscribe linux-crypto in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH, RFC] random: introduce getrandom(2) system call
On Thu, Jul 17, 2014 at 05:18:15AM -0400, Theodore Ts'o wrote: The getrandom(2) system call was requested by the LibreSSL Portable developers. It is analoguous to the getentropy(2) system call in OpenBSD. What's the reason to not implement exactly the same system call OpenBSD does? Having slightly different names and semantics for the same functionality is highly annoying. -- To unsubscribe from this list: send the line unsubscribe linux-crypto in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH, RFC] random: introduce getrandom(2) system call
On Thu, Jul 17, 2014 at 09:12:15AM -0700, Christoph Hellwig wrote:
On Thu, Jul 17, 2014 at 05:18:15AM -0400, Theodore Ts'o wrote:
The getrandom(2) system call was requested by the LibreSSL Portable
developers. It is analoguous to the getentropy(2) system call in
OpenBSD.
What's the reason to not implement exactly the same system call OpenBSD
does? Having slightly different names and semantics for the same
functionality is highly annoying.
The getrandom(2) system call is a superset of getentropy(2). When we
add the support for this into glibc, it won't be terribly difficult
nor annoying to drop the following in alongside the standard support
needed for any new system call:
int getentropy(void *buf, size_t buflen)
{
int ret;
ret = getentropy(buf, buflen, 0);
return (ret 0) ? 0 : ret;
}
The reason for the additional flags is that I'm trying to solve more
problems than just getentropy()'s raison d'etre. The discussion of
this is in the commit description; let me know if there bits that I
could make clearer.
Cheers,
- Ted
--
To unsubscribe from this list: send the line unsubscribe linux-crypto in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH, RFC] random: introduce getrandom(2) system call
Hi Ted, yeah I understand the reasoning, it would be good if there was
a way to influence the various libc people to
ensure they manage to provide a getentropy().
On Thu, Jul 17, 2014 at 11:01 AM, Theodore Ts'o ty...@mit.edu wrote:
On Thu, Jul 17, 2014 at 09:12:15AM -0700, Christoph Hellwig wrote:
On Thu, Jul 17, 2014 at 05:18:15AM -0400, Theodore Ts'o wrote:
The getrandom(2) system call was requested by the LibreSSL Portable
developers. It is analoguous to the getentropy(2) system call in
OpenBSD.
What's the reason to not implement exactly the same system call OpenBSD
does? Having slightly different names and semantics for the same
functionality is highly annoying.
The getrandom(2) system call is a superset of getentropy(2). When we
add the support for this into glibc, it won't be terribly difficult
nor annoying to drop the following in alongside the standard support
needed for any new system call:
int getentropy(void *buf, size_t buflen)
{
int ret;
ret = getentropy(buf, buflen, 0);
return (ret 0) ? 0 : ret;
}
The reason for the additional flags is that I'm trying to solve more
problems than just getentropy()'s raison d'etre. The discussion of
this is in the commit description; let me know if there bits that I
could make clearer.
Cheers,
- Ted
--
To unsubscribe from this list: send the line unsubscribe linux-crypto in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH, RFC] random: introduce getrandom(2) system call
On Thu, Jul 17, 2014 at 11:05:01AM -0600, Bob Beck wrote: Hi Ted, yeah I understand the reasoning, it would be good if there was a way to influence the various libc people to ensure they manage to provide a getentropy(). I don't anticipate that to be a problem. And before they do, and/or if you are dealing with a system where the kernel has been upgraded, but not libc, you have your choice of either sticking with the binary_sysctl approach, or calling getrandom directly using the syscall method; and in that case, whether we use getrandom() or provide an exact getentropy() replacement system call isn't that much difference, since you'd have to have Linux-specific workaround code anyway - Ted -- To unsubscribe from this list: send the line unsubscribe linux-crypto in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH, RFC] random: introduce getrandom(2) system call
we have diffs pending that will do the syscall method until we start to see it in libc :) So basically we're going to put that in right away :) On Thu, Jul 17, 2014 at 11:34 AM, Theodore Ts'o ty...@mit.edu wrote: On Thu, Jul 17, 2014 at 11:05:01AM -0600, Bob Beck wrote: Hi Ted, yeah I understand the reasoning, it would be good if there was a way to influence the various libc people to ensure they manage to provide a getentropy(). I don't anticipate that to be a problem. And before they do, and/or if you are dealing with a system where the kernel has been upgraded, but not libc, you have your choice of either sticking with the binary_sysctl approach, or calling getrandom directly using the syscall method; and in that case, whether we use getrandom() or provide an exact getentropy() replacement system call isn't that much difference, since you'd have to have Linux-specific workaround code anyway - Ted -- To unsubscribe from this list: send the line unsubscribe linux-crypto in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH, RFC] random: introduce getrandom(2) system call
And thanks btw. I don't suppose you guys know who we should talk to about possibly getting MAP_INHERIT_ZERO minherit() support? On Thu, Jul 17, 2014 at 11:45 AM, Bob Beck b...@openbsd.org wrote: we have diffs pending that will do the syscall method until we start to see it in libc :) So basically we're going to put that in right away :) On Thu, Jul 17, 2014 at 11:34 AM, Theodore Ts'o ty...@mit.edu wrote: On Thu, Jul 17, 2014 at 11:05:01AM -0600, Bob Beck wrote: Hi Ted, yeah I understand the reasoning, it would be good if there was a way to influence the various libc people to ensure they manage to provide a getentropy(). I don't anticipate that to be a problem. And before they do, and/or if you are dealing with a system where the kernel has been upgraded, but not libc, you have your choice of either sticking with the binary_sysctl approach, or calling getrandom directly using the syscall method; and in that case, whether we use getrandom() or provide an exact getentropy() replacement system call isn't that much difference, since you'd have to have Linux-specific workaround code anyway - Ted -- To unsubscribe from this list: send the line unsubscribe linux-crypto in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH, RFC] random: introduce getrandom(2) system call
Or perhaps to put that another way, since you don't do minherit - maybe a FORK_ZERO for madvise? or a similar way to do that? On Thu, Jul 17, 2014 at 11:46 AM, Bob Beck b...@openbsd.org wrote: And thanks btw. I don't suppose you guys know who we should talk to about possibly getting MAP_INHERIT_ZERO minherit() support? On Thu, Jul 17, 2014 at 11:45 AM, Bob Beck b...@openbsd.org wrote: we have diffs pending that will do the syscall method until we start to see it in libc :) So basically we're going to put that in right away :) On Thu, Jul 17, 2014 at 11:34 AM, Theodore Ts'o ty...@mit.edu wrote: On Thu, Jul 17, 2014 at 11:05:01AM -0600, Bob Beck wrote: Hi Ted, yeah I understand the reasoning, it would be good if there was a way to influence the various libc people to ensure they manage to provide a getentropy(). I don't anticipate that to be a problem. And before they do, and/or if you are dealing with a system where the kernel has been upgraded, but not libc, you have your choice of either sticking with the binary_sysctl approach, or calling getrandom directly using the syscall method; and in that case, whether we use getrandom() or provide an exact getentropy() replacement system call isn't that much difference, since you'd have to have Linux-specific workaround code anyway - Ted -- To unsubscribe from this list: send the line unsubscribe linux-crypto in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH, RFC] random: introduce getrandom(2) system call
On Thu, Jul 17, 2014, Theodore Ts'o wrote:
The getrandom(2) system call is a superset of getentropy(2). When we
add the support for this into glibc, it won't be terribly difficult
nor annoying to drop the following in alongside the standard support
needed for any new system call:
int getentropy(void *buf, size_t buflen)
{
int ret;
ret = getentropy(buf, buflen, 0);
return (ret 0) ? 0 : ret;
}
I'm sure you meant to use getrandom() there ;)
Since for LibreSSL we'd want a getentropy() that cannot fail the
getrandom() call should use GRND_BLOCK flag. Actually it makes sense
(to me) to make blocking the default behaviour and have a
BRND_NONBLOCK flag. Much in the same way as you need to specify
O_NONBLOCK if you want non-blocking behaviour for files.
--
To unsubscribe from this list: send the line unsubscribe linux-crypto in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH, RFC] random: introduce getrandom(2) system call
On Thu, Jul 17, 2014 at 05:18:15AM -0400, Theodore Ts'o wrote:
Minor nit:
@@ -469,6 +471,8 @@ static struct entropy_store nonblocking_pool = {
push_to_pool),
};
+DECLARE_COMPLETION(urandom_initialized);
+
static DECLARE_COMPLETION(urandom_initialized);
instead?
thanks,
greg k-h
--
To unsubscribe from this list: send the line unsubscribe linux-crypto in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH, RFC] random: introduce getrandom(2) system call
On Thu, Jul 17, 2014 at 05:18:15AM -0400, Theodore Ts'o wrote:
+SYSCALL_DEFINE3(getrandom, char __user *, buf, size_t, count,
+ unsigned int, flags)
+{
+ int r;
+
+ if (count 256)
+ return -EINVAL;
+
+ if (flags GRND_RANDOM) {
+ return _random_read(!(flags GRND_BLOCK), buf, count);
+ }
+ if (flags GRND_BLOCK) {
+ r = wait_for_completion_interruptible(urandom_initialized);
+ if (r)
+ return r;
+ } else if (!completion_done(urandom_initialized))
+ return -EAGAIN;
+ return urandom_read(NULL, buf, count, NULL);
+}
You should fail if any other bits are set that you don't understand in
the flags value, to make it easier for newer kernels with more flags to
fail properly on old kernel releases.
thanks,
greg k-h
--
To unsubscribe from this list: send the line unsubscribe linux-crypto in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH, RFC] random: introduce getrandom(2) system call
Hey Ted, one more nit. Yes, I have a bicycle too.. I see here we add a flag to make it block - whereas it seems most other system calls that can block the flag is added to make it not block (I.E. O_NONBLOCK, etc. etc.) Would it make more sense to invert this so it was more like the typical convention in other system calls? On Thu, Jul 17, 2014 at 11:34 AM, Theodore Ts'o ty...@mit.edu wrote: On Thu, Jul 17, 2014 at 11:05:01AM -0600, Bob Beck wrote: Hi Ted, yeah I understand the reasoning, it would be good if there was a way to influence the various libc people to ensure they manage to provide a getentropy(). I don't anticipate that to be a problem. And before they do, and/or if you are dealing with a system where the kernel has been upgraded, but not libc, you have your choice of either sticking with the binary_sysctl approach, or calling getrandom directly using the syscall method; and in that case, whether we use getrandom() or provide an exact getentropy() replacement system call isn't that much difference, since you'd have to have Linux-specific workaround code anyway - Ted -- To unsubscribe from this list: send the line unsubscribe linux-crypto in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH, RFC] random: introduce getrandom(2) system call
SYNOPSIS
#include linux/random.h
int getrandom(void *buf, size_t buflen, unsigned int flags);
I certainly like the idea of getting entropy without having to worry
about fds.
If the GRND_RANDOM flags bit is not set, then the /dev/raundom
(raundom typo)
RETURN VALUE
On success, the number of bytes that was returned is returned.
The description talks about filling the buffer, maybe say 'the number of
bytes filled is returned'?
+DECLARE_COMPLETION(urandom_initialized);
static?
+SYSCALL_DEFINE3(getrandom, char __user *, buf, size_t, count,
+ unsigned int, flags)
+{
+ int r;
+
Michael Kerrisk wants you to return -EINVAL on unknown flags :)
http://lwn.net/Articles/588444/
+ if (count 256)
+ return -EINVAL;
I'd vote for not having the limit. It seems easy enough to iterate over
the buffer. We'd need to clamp the count to ssize_t, though.
+ if (flags GRND_RANDOM) {
+ return _random_read(!(flags GRND_BLOCK), buf, count);
+ }
Do we want it to block by default and have the flag be _NONBLOCK? Feels
more.. familiar.
+ if (flags GRND_BLOCK) {
+ r = wait_for_completion_interruptible(urandom_initialized);
+ if (r)
+ return r;
I can *never* remember the rules for -ERESTARTSYS. The syscall callers
take care of this?
+ return urandom_read(NULL, buf, count, NULL);
I wonder if we want to refactor the entry points a bit more instead of
directly calling the device read functions. get_random_bytes() and
urandom_read() both have their own uninitialied use warning message and
tracing. Does the syscall want its own little extraction function as
well?
- z
--
To unsubscribe from this list: send the line unsubscribe linux-crypto in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH, RFC] random: introduce getrandom(2) system call
On 07/17/2014 02:18 AM, Theodore Ts'o wrote: The getrandom(2) system call was requested by the LibreSSL Portable developers. It is analoguous to the getentropy(2) system call in OpenBSD. The rationale of this system call is to provide resiliance against file descriptor exhaustion attacks, where the attacker consumes all available file descriptors, forcing the use of the fallback code where /dev/[u]random is not available. Since the fallback code is often not well-tested, it is better to eliminate this potential failure mode entirely. The other feature provided by this new system call is the ability to request randomness from the /dev/urandom entropy pool, but to block until at least 128 bits of entropy has been accumulated in the /dev/urandom entropy pool. Historically, the emphasis in the /dev/urandom development has been to ensure that urandom pool is initialized as quickly as possible after system boot, and preferably before the init scripts start execution. This is because changing /dev/urandom reads to block represents an interface change that could potentially break userspace which is not acceptable. In practice, on most x86 desktop and server systems, in general the entropy pool can be initialized before it is needed (and in modern kernels, we will printk a warning message if not). However, on an embedded system, this may not be hte case. And so with a new interface, we can provide this requested functionality of blocking until the urandom pool has been initialized. 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. SYNOPSIS #include linux/random.h int getrandom(void *buf, size_t buflen, unsigned int flags); DESCRIPTION The system call getrandom() fills the buffer pointed to by buf with up to buflen random bytes which can be used to seed user space random number generators (i.e., DRBG's) or for other cryptographic processes. It should not be used Monte Carlo simulations or for other probabilistic sampling applications. 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. RETURN VALUE On success, the number of bytes that was returned is returned. On error, -1 is returned, and errno is set appropriately ERRORS EINVAL The buflen value was invalid. EFAULT buf is outside your accessible address space. EAGAIN The requested entropy was not available, and the getentropy(2) would have blocked if GRND_BLOCK flag was set. Signed-off-by: Theodore Ts'o ty...@mit.edu --- arch/x86/syscalls/syscall_32.tbl | 1 + arch/x86/syscalls/syscall_64.tbl | 1 + drivers/char/random.c | 35 +-- include/linux/syscalls.h | 3 +++ include/uapi/asm-generic/unistd.h | 4 +++- include/uapi/linux/random.h | 9 + 6 files changed, 50 insertions(+), 3 deletions(-) diff --git a/arch/x86/syscalls/syscall_32.tbl b/arch/x86/syscalls/syscall_32.tbl index d6b8679..f484e39 100644 --- a/arch/x86/syscalls/syscall_32.tbl +++ b/arch/x86/syscalls/syscall_32.tbl @@ -360,3 +360,4 @@ 351 i386sched_setattr sys_sched_setattr 352 i386sched_getattr sys_sched_getattr 353 i386renameat2 sys_renameat2 +354 i386getrandom sys_getrandom diff --git a/arch/x86/syscalls/syscall_64.tbl b/arch/x86/syscalls/syscall_64.tbl index ec255a1..6705032 100644 --- a/arch/x86/syscalls/syscall_64.tbl +++ b/arch/x86/syscalls/syscall_64.tbl @@ -323,6 +323,7 @@ 314 common sched_setattr sys_sched_setattr 315 common sched_getattr sys_sched_getattr 316 common renameat2 sys_renameat2 +317 common getrandom sys_getrandom # # x32-specific system call numbers start at 512 to avoid cache impact diff --git a/drivers/char/random.c b/drivers/char/random.c index aa22fe5..76a56f6 100644 --- a/drivers/char/random.c
Re: [PATCH, RFC] random: introduce getrandom(2) system call
On 07/17/2014 11:48 AM, Mark Kettenis wrote:
On Thu, Jul 17, 2014, Theodore Ts'o wrote:
The getrandom(2) system call is a superset of getentropy(2). When we
add the support for this into glibc, it won't be terribly difficult
nor annoying to drop the following in alongside the standard support
needed for any new system call:
int getentropy(void *buf, size_t buflen)
{
int ret;
ret = getentropy(buf, buflen, 0);
return (ret 0) ? 0 : ret;
}
I'm sure you meant to use getrandom() there ;)
Since for LibreSSL we'd want a getentropy() that cannot fail the
getrandom() call should use GRND_BLOCK flag. Actually it makes sense
(to me) to make blocking the default behaviour and have a
BRND_NONBLOCK flag. Much in the same way as you need to specify
O_NONBLOCK if you want non-blocking behaviour for files.
Can we please have a mode in which getrandom(2) can neither block nor
fail? If that gets added, then this can replace things like AT_RANDOM.
There are non-crypto things out there that will want this. There are
also probably VM systems (especially ones that have something like my
KVM_GET_RNG_SEED patches applied, or many VMs on Haswell, for that
matter) that will have perfectly fine cryptographically secure urandom
output immediately after bootup but that won't consider themselves
initialized for a while. At least these will be perfectly fine from
the POV of those who trust their hypervisor and Intel :)
--Andy
--
To unsubscribe from this list: send the line unsubscribe linux-crypto in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH, RFC] random: introduce getrandom(2) system call
On Thu, Jul 17, 2014 at 01:27:06PM -0700, Andy Lutomirski wrote: + return urandom_read(NULL, buf, count, NULL); This can return -ERESTARTSYS. Does it need any logic to restart correctly? Nope; because we only return -ERESTARTSYS when we haven't generated any randomness yet. The way /dev/urandom and /dev/random devices work is that if we get interrupted, we return a short read. We do *not* resume generation of random bytes from where we got interrupted from the signal handler. This is consistent with the definition in the signal(7) man page: If a blocked call to one of the following interfaces is interrupted by a signal handler, then the call will be automatically restarted after the signal handler returns if the SA_RESTART flag was used; otherwise the call will fail with the error EINTR: * read(2), readv(2), write(2), writev(2), and ioctl(2) calls on slow devices. A slow device is one where the I/O call may block for an indefinite time, for example, a terminal, pipe, or socket. (A disk is not a slow device according to this definition.) If an I/O call on a slow device has already transferred some data by the time it is interrupted by a signal handler, then the call will return a success status (normally, the number of bytes transferred). And in answer to Zach's question along these lines, ERESTARTSYS gets restarted or transformed into EINTR by the system call layer, so long as you only set ERESTARTSYS when signal_pending(current) is true. If you accidentally set the return value to ERESTARTSYS when a signal is not pending, this error code can escape out to user space, which is considered a bug. But we're using this correctly in drivers/char/random.c. - Ted -- To unsubscribe from this list: send the line unsubscribe linux-crypto in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH, RFC] random: introduce getrandom(2) system call
On Thu, Jul 17, 2014 at 01:35:15PM -0700, Andy Lutomirski wrote: Can we please have a mode in which getrandom(2) can neither block nor fail? If that gets added, then this can replace things like AT_RANDOM. AT_RANDOM has been around for a long time; it's not something we can remove. There are non-crypto things out there that will want this. There are also probably VM systems (especially ones that have something like my KVM_GET_RNG_SEED patches applied, or many VMs on Haswell, for that matter) that will have perfectly fine cryptographically secure urandom output immediately after bootup but that won't consider themselves initialized for a while. At least these will be perfectly fine from the POV of those who trust their hypervisor and Intel :) If you trust Intel, then you can either use RDRAND directly, or you can use rngd. There is also plans to set up an hw_random RDRAND that can be configured to automatically fill the entropy pool using the new khwrngd, which could be configured using the appropriate boot options for those who want to blindly trus their hypervisor and/or Intel. However, I don't think that should be the default. And on x86 systems at least, this is largely a moot point, since the /dev/urandom pool gets initialized *very* quickly after the system boots. It's only on the !@#! ARM systems that don't have a cycle counter, or apparently no reliable way to make sure the cycle counter is present, which seems to be the place where we have problems. But I'd much rather gradually apply more pressure to the ARM folks so they finally fix their CPU architecture, and this is one step down that path without forcibly breaking existing userspace. - Ted -- To unsubscribe from this list: send the line unsubscribe linux-crypto in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH, RFC] random: introduce getrandom(2) system call
On Thu, Jul 17, 2014 at 12:48:12PM -0700, Zach Brown wrote: + return urandom_read(NULL, buf, count, NULL); I wonder if we want to refactor the entry points a bit more instead of directly calling the device read functions. get_random_bytes() and urandom_read() both have their own uninitialied use warning message and tracing. Does the syscall want its own little extraction function as well? I'm not sure what warning you are worried about? urandom_read() never uses file or ppos, so passing in NULL works just fine as near as I can tell. I could refactor the entropy point, but it probably wouldn't add any extra bloat, since the compiler would hopefully compile it away, but adding the extra static function would seem to make things less readable at least in my opinion. - Ted -- To unsubscribe from this list: send the line unsubscribe linux-crypto in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH, RFC] random: introduce getrandom(2) system call
On Thu, Jul 17, 2014 at 2:28 PM, Theodore Ts'o ty...@mit.edu wrote: On Thu, Jul 17, 2014 at 01:35:15PM -0700, Andy Lutomirski wrote: Can we please have a mode in which getrandom(2) can neither block nor fail? If that gets added, then this can replace things like AT_RANDOM. AT_RANDOM has been around for a long time; it's not something we can remove. I'm not suggesting removing AT_RANDOM. To the contrary, I'm suggesting that libraries that need to seed some kind of non-cryptographic, non-security-related RNG could use getrandom(2) with appropriate flags rather than screwing around with getpid, clock_gettime, etc. For example: unsigned int seed; getrandom(seed, sizeof(seed), GRND_BEST_EFFORT); /* Never fails on new enough kernels */ srand(seed); No error checking, no weird cases, and if the RNG isn't well seeded, then I tried my best. --Andy -- To unsubscribe from this list: send the line unsubscribe linux-crypto in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH, RFC] random: introduce getrandom(2) system call
On Thu, Jul 17, 2014 at 04:54:17PM -0400, Theodore Ts'o wrote: On Thu, Jul 17, 2014 at 12:48:12PM -0700, Zach Brown wrote: + return urandom_read(NULL, buf, count, NULL); I wonder if we want to refactor the entry points a bit more instead of directly calling the device read functions. I could refactor the entropy point, but it probably wouldn't add any extra bloat, since the compiler would hopefully compile it away, but adding the extra static function would seem to make things less readable at least in my opinion. Fair enough, I don't have a strong preference either way. It was just something I noticed when leafing through the (unfamiliar) code. - z -- To unsubscribe from this list: send the line unsubscribe linux-crypto in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH, RFC] random: introduce getrandom(2) system call
On Thu, Jul 17, 2014 at 11:45:56AM -0600, Bob Beck wrote: we have diffs pending that will do the syscall method until we start to see it in libc :) One warning --- please don't check in the syscall number until it actually hits mainline. Kees has another patch outstanding for seccomp(2) that is using the same syscall numbers I have in my patch. Please treat the numbers in my patch as placeholders until it has been accepted and we see what numbers we actually get assigned. Thanks, - Ted -- To unsubscribe from this list: send the line unsubscribe linux-crypto in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
