Re: [PATCH -v5] random: introduce getrandom(2) system call
Theodore Ts'o wrote: It's me again, finding only one issue per cycle :/ EAGAIN The requested entropy was not available, and getentropy(2) would have blocked if GRND_BLOCK flag was set. if GRND_NONBLOCK flag was not set Eike -- 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 -v5] random: introduce getrandom(2) system call
On Thu, 24 Jul 2014, Theodore Ts'o wrote: On Thu, Jul 24, 2014 at 05:30:19PM -0300, Henrique de Moraes Holschuh wrote: I wouldn't add the error to the man page until we actually modify the kernel to add such a restriction. By then, it might be too late. It would be really sad to find ourselves forced to return ENOSYS to getrandom(GRND_RANDOM) when we actually wanted to return EPERM/EACCES. I wouldn't worry about. The reality is that anyone using GRND_RANDOM has to be checking for error codes anyway, and if they do something ... In general, all system calls can return errno's other than the ones documented in the man page. This is certainly true for open(2), and read(2) if you are using a network file system such as NFS. Someone A few manpages might actually have warnings to that effect, but it is not the rule. Amusingly enough, the one for read(2) does, while open(2) does not. IMHO the getrandom(2) case is slightly different: we already know to a high degree of confidence that we will want to convey a permission denied condition to userspace for getrandom(GRND_RANDOM) sooner or later. I'd be fine with text that mentions that GRND_RANDOM access by a process may be restricted/rejected by system policy in the future, so code should not assume any error return code from getrandom(GRND_RANDOM) would also apply to getrandom() without GRND_RANDOM, and must degrade gracefully and safely in that case. I don't think it's necessary to add a sentence that other errors can be returned in the future, and users much check for other errors, but if you really think people are that stupid that we need to say something which is true for every single system call in Linux, we can do that Well, I feel we could go a bit further than usual for getrandom(2), but I've already stated my case. -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh -- 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 -v5] random: introduce getrandom(2) system call
On Thu, Jul 24, 2014 at 04:27:36PM -0700, Andy Lutomirski wrote: I think that people might do: try getrandom(GRND_RANDOM) fall back to /dev/random fall back to something intensely stupid We want them to at least attempt the fallback from GRND_RANDOM to !GRND_RANDOM. We can't legislate against stupidity. Seriously, the best way to do this is to write a good userspace library and encourage application writers to use it. Regards, - 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 -v5] random: introduce getrandom(2) system call
On Thu, 24 Jul 2014, Theodore Ts'o wrote: ERRORS EINVAL An invalid flag was passed to getrandom(2) EFAULT buf is outside the accessible address space. EAGAIN The requested entropy was not available, and getentropy(2) would have blocked if GRND_BLOCK flag was set. EINTR While blocked waiting for entropy, the call was interrupted by a signal handler; see the description of how interrupted read(2) calls on slow devices are handled with and without the SA_RESTART flag in the signal(7) man page. Should we add ESOMETHING to be able to deny access to GRND_RANDOM or some future extension ? -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh -- 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 -v5] random: introduce getrandom(2) system call
On Thu, Jul 24, 2014 at 8:18 AM, Henrique de Moraes Holschuh h...@hmh.eng.br wrote: On Thu, 24 Jul 2014, Theodore Ts'o wrote: ERRORS EINVAL An invalid flag was passed to getrandom(2) EFAULT buf is outside the accessible address space. EAGAIN The requested entropy was not available, and getentropy(2) would have blocked if GRND_BLOCK flag was set. EINTR While blocked waiting for entropy, the call was interrupted by a signal handler; see the description of how interrupted read(2) calls on slow devices are handled with and without the SA_RESTART flag in the signal(7) man page. Should we add ESOMETHING to be able to deny access to GRND_RANDOM or some future extension ? This might actually be needed sooner rather than later. There are programs that use containers and intentionally don't pass /dev/random through into the container. I know that Sandstorm does this, and I wouldn't be surprised if other things (Docker?) do the same thing. --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 -v5] random: introduce getrandom(2) system call
On Thu, 24 Jul 2014, Theodore Ts'o wrote: On Thu, Jul 24, 2014 at 08:21:38AM -0700, Andy Lutomirski wrote: Should we add ESOMETHING to be able to deny access to GRND_RANDOM or some future extension ? This might actually be needed sooner rather than later. There are programs that use containers and intentionally don't pass /dev/random through into the container. I know that Sandstorm does this, and I wouldn't be surprised if other things (Docker?) do the same thing. I wouldn't add the error to the man page until we actually modify the kernel to add such a restriction. By then, it might be too late. It would be really sad to find ourselves forced to return ENOSYS to getrandom(GRND_RANDOM) when we actually wanted to return EPERM/EACCES. Actually, we might not be able to do even that much: all it takes is for someone to have the bright idea of deploying userspace code that checks for ENOSYS only on a first probe getrandom() syscall without GRND_RANDOM, and does something idiotic when it gets ENOSYS later on a getrandom(GRND_RANDOM). meh. We can't even abuse the system ourselves :-) However, the thought crossed my mind a while back that perhaps the right answer is a cgroup controller which controls the rate at which a process is allowed to drain entropy from the /dev/random pool. This could be set to 0, or it could be set to N bits per unit time T, and if the process exceeded the value, it would just block or return EAGAIN. So instead of making it be just a binary you have access or That will teach people to not have a SIGALRM on code that calls a blocking syscall, I suppose. Still, there is a risk it could cause so much bad application behaviour to the point of being unusable. Then I decided that it was overkill, but for people who are trying to Indeed :p -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh -- 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 -v5] random: introduce getrandom(2) system call
On Thu, Jul 24, 2014 at 1:30 PM, Henrique de Moraes Holschuh h...@hmh.eng.br wrote: On Thu, 24 Jul 2014, Theodore Ts'o wrote: On Thu, Jul 24, 2014 at 08:21:38AM -0700, Andy Lutomirski wrote: Should we add ESOMETHING to be able to deny access to GRND_RANDOM or some future extension ? This might actually be needed sooner rather than later. There are programs that use containers and intentionally don't pass /dev/random through into the container. I know that Sandstorm does this, and I wouldn't be surprised if other things (Docker?) do the same thing. I wouldn't add the error to the man page until we actually modify the kernel to add such a restriction. By then, it might be too late. It would be really sad to find ourselves forced to return ENOSYS to getrandom(GRND_RANDOM) when we actually wanted to return EPERM/EACCES. Actually, we might not be able to do even that much: all it takes is for someone to have the bright idea of deploying userspace code that checks for ENOSYS only on a first probe getrandom() syscall without GRND_RANDOM, and does something idiotic when it gets ENOSYS later on a getrandom(GRND_RANDOM). meh. We can't even abuse the system ourselves :-) Or that someone writes userspace code that gets -EPERM/-EACCESS on getrandom with GRND_RANDOM and falls back to something worse than getrandom w/o GRND_RANDOM. --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 -v5] random: introduce getrandom(2) system call
On Thu, Jul 24, 2014 at 05:30:19PM -0300, Henrique de Moraes Holschuh wrote: I wouldn't add the error to the man page until we actually modify the kernel to add such a restriction. By then, it might be too late. It would be really sad to find ourselves forced to return ENOSYS to getrandom(GRND_RANDOM) when we actually wanted to return EPERM/EACCES. I wouldn't worry about. The reality is that anyone using GRND_RANDOM has to be checking for error codes anyway, and if they do something stupid because the system call returns EPERM/EACCESS when they weren't expecting it, again, they are much more likely to be making many other fatal mistakes anyway. In general, all system calls can return errno's other than the ones documented in the man page. This is certainly true for open(2), and read(2) if you are using a network file system such as NFS. Someone who assumes that the only errors that they have to handle is the list in the man page, and assumes that this list is an exhaustive listing of all possible errors, is going to be in a *world* of hurt. I don't think it's necessary to add a sentence that other errors can be returned in the future, and users much check for other errors, but if you really think people are that stupid that we need to say something which is true for every single system call in Linux, we can do that - 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 -v5] random: introduce getrandom(2) system call
On 07/24/2014 01:54 PM, Andy Lutomirski wrote: Or that someone writes userspace code that gets -EPERM/-EACCESS on getrandom with GRND_RANDOM and falls back to something worse than getrandom w/o GRND_RANDOM. -ENXIO? -hpa -- 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
