Displaying 10 results from an estimated 10 matches for "input_pool".
Did you mean:
input_loop
2016 Jul 29
2
getrandom waits for a long time when /dev/random is insufficiently read from
...t;
> What I am saying is that based on my understanding of random(4) and
> getrandom(2), at boot, given the same buffer size, reading
> from /dev/random should have the same behavior as calling getrandom
> passing no flags.
/dev/random can return after at least 64 bits received in the input_pool
whereas getrandom waits for 128 bits.
>
> The buffer size can also be set to 1 with similar results, but the
> iteration number for success must be then increased to a large number.
> IME 30 worked consistently while 29 hung; your results may vary.
>
> The interesting thing is...
2016 Jul 29
2
getrandom waits for a long time when /dev/random is insufficiently read from
...t;
> What I am saying is that based on my understanding of random(4) and
> getrandom(2), at boot, given the same buffer size, reading
> from /dev/random should have the same behavior as calling getrandom
> passing no flags.
/dev/random can return after at least 64 bits received in the input_pool
whereas getrandom waits for 128 bits.
>
> The buffer size can also be set to 1 with similar results, but the
> iteration number for success must be then increased to a large number.
> IME 30 worked consistently while 29 hung; your results may vary.
>
> The interesting thing is...
2016 Jul 29
2
getrandom waits for a long time when /dev/random is insufficiently read from
...).
getrandom *only* differs from /dev/*u*random in that it waits initially such
that the system collected 128 bits of entropy.
But you point to a real issue: when /dev/random is pulled before getrandom
(and yet insufficient entropy is present), then the getrandom call will be
woken up when the input_pool received 128 bits. But those 128 bits are fed
from the input_pool to the blocking_pool based on the caller at the /dev/
random device. This implies that the reader for getrandom will NOT be able to
obtain data from the input_pool and the nonblocking_pool because the transfer
operation will not s...
2016 Jul 29
2
getrandom waits for a long time when /dev/random is insufficiently read from
...).
getrandom *only* differs from /dev/*u*random in that it waits initially such
that the system collected 128 bits of entropy.
But you point to a real issue: when /dev/random is pulled before getrandom
(and yet insufficient entropy is present), then the getrandom call will be
woken up when the input_pool received 128 bits. But those 128 bits are fed
from the input_pool to the blocking_pool based on the caller at the /dev/
random device. This implies that the reader for getrandom will NOT be able to
obtain data from the input_pool and the nonblocking_pool because the transfer
operation will not s...
2016 Jul 29
0
getrandom waits for a long time when /dev/random is insufficiently read from
...itially such that the system collected 128 bits of entropy.
I agree, this is the documented behavior of getrandom.
> But you point to a real issue: when /dev/random is pulled before
> getrandom (and yet insufficient entropy is present), then the
> getrandom call will be woken up when the input_pool received 128
> bits. But those 128 bits are fed from the input_pool to the
> blocking_pool based on the caller at the /dev/ random device. This
> implies that the reader for getrandom will NOT be able to obtain data
> from the input_pool and the nonblocking_pool because the transfer
>...
2016 Jul 29
2
getrandom waits for a long time when /dev/random is insufficiently read from
On Fri, Jul 29, 2016 at 7:40 AM, Stephan Mueller <smueller at chronox.de> wrote:
> And finally, you have a coding error that is very very common but fatal when
> reading from /dev/random: you do not account for short reads which implies
> that your loop continues even in the case of short reads.
>
> Fix your code with something like the following:
> int read_random(char
2016 Jul 29
2
getrandom waits for a long time when /dev/random is insufficiently read from
On Fri, Jul 29, 2016 at 7:40 AM, Stephan Mueller <smueller at chronox.de> wrote:
> And finally, you have a coding error that is very very common but fatal when
> reading from /dev/random: you do not account for short reads which implies
> that your loop continues even in the case of short reads.
>
> Fix your code with something like the following:
> int read_random(char
2016 Jul 29
0
getrandom waits for a long time when /dev/random is insufficiently read from
...x Xu:
Hi Alex,
> Linux 4.6, also tried 4.7, qemu 2.6, using this C program:
I am not sure what problem you are referring to, but that is an expected
behavior.
You get partial reads when reading from /dev/random with a minimum of 64
bits. On the other hand getrandom(2) is woken up after the input_pool
received 128 bits of entropy.
In you strace you see that after reading 16 bytes from /dev/random, the
getrandom unblocks and starts delivering.
Note, in virtualized environments the current Linux /dev/random
implementation collects massively less entropy compared to a bare-metal
system. Hence...
2016 Jul 28
2
getrandom waits for a long time when /dev/random is insufficiently read from
Linux 4.6, also tried 4.7, qemu 2.6, using this C program:
#include <fcntl.h>
#include <stdlib.h>
#include <syscall.h>
#include <unistd.h>
int main(int argc, char *argv[]) {
char buf[16];
int fd;
if (argc != 2)
return 1;
for (int i = 0; i < atoi(argv[1]); i++) {
sleep(1);
if ((fd = open("/dev/random", O_RDONLY)) ==
2016 Jul 28
2
getrandom waits for a long time when /dev/random is insufficiently read from
Linux 4.6, also tried 4.7, qemu 2.6, using this C program:
#include <fcntl.h>
#include <stdlib.h>
#include <syscall.h>
#include <unistd.h>
int main(int argc, char *argv[]) {
char buf[16];
int fd;
if (argc != 2)
return 1;
for (int i = 0; i < atoi(argv[1]); i++) {
sleep(1);
if ((fd = open("/dev/random", O_RDONLY)) ==