search for: getrandom

...200 > > Stephan Mueller <smueller at chronox.de> wrote as excerpted: > > Am Freitag, 29. Juli 2016, 09:03:45 CEST schrieb Alex Xu: > > > In my opinion, assuming I am not doing something terribly wrong, > > > this constitutes a bug in the kernel's handling of getrandom calls > > > at boot, possibly only when the primary source of entropy is > > > virtio. > > > > Nope, I do not think that this is true: > > > > - /dev/random returns one byte for one byte of entropy received, but > > it has a lower limit of 64 bits &...

...200 > > Stephan Mueller <smueller at chronox.de> wrote as excerpted: > > Am Freitag, 29. Juli 2016, 09:03:45 CEST schrieb Alex Xu: > > > In my opinion, assuming I am not doing something terribly wrong, > > > this constitutes a bug in the kernel's handling of getrandom calls > > > at boot, possibly only when the primary source of entropy is > > > virtio. > > > > Nope, I do not think that this is true: > > > > - /dev/random returns one byte for one byte of entropy received, but > > it has a lower limit of 64 bits &...

...+ len), (buflen - len)); > if (0 < ret) > len += ret; > } while ((0 < ret || EINTR == errno || ERESTART == errno) > && buflen > len); Unless there is a documentation error, the same is required when using getrandom(). It can also return short as well as to be interrupted. regards, Nikos

...+ len), (buflen - len)); > if (0 < ret) > len += ret; > } while ((0 < ret || EINTR == errno || ERESTART == errno) > && buflen > len); Unless there is a documentation error, the same is required when using getrandom(). It can also return short as well as to be interrupted. regards, Nikos

...ret; > > > > > > } while ((0 < ret || EINTR == errno || ERESTART == errno) > > > > > > && buflen > len); > > > > Unless there is a documentation error, the same is required when using > > getrandom(). It can also return short as well as to be interrupted. > > > > regards, > > Nikos > > I am aware that (according to the documentation) both random(4) and > getrandom(2) may not return the full size of the read. However, that is > (as far as I know) not relevant to...

...ret; > > > > > > } while ((0 < ret || EINTR == errno || ERESTART == errno) > > > > > > && buflen > len); > > > > Unless there is a documentation error, the same is required when using > > getrandom(). It can also return short as well as to be interrupted. > > > > regards, > > Nikos > > I am aware that (according to the documentation) both random(4) and > getrandom(2) may not return the full size of the read. However, that is > (as far as I know) not relevant to...

...: > Am Freitag, 29. Juli 2016, 10:14:07 CEST schrieb Alex Xu: > > I don't follow. Assuming you are correct and this is the issue, then > > reading 128 bits (16 bytes) from /dev/random should "exhaust the > > supply" and then both reads from /dev/random and calling getrandom > > should block. > > You assume that getrandom works like /dev/random. This is not the > case. It is a full deterministic RNG like /dev/urandom (which is > seeded during its operation as entropy is available). My understanding was that all three methods of obtaining entropy f...

Hello When booting from a slow machine, I can observe dovecot blocking the whole boot process. I traced it down to the getrandom() system call in lib/randgen.c, which blocks until the random number generator is initialized (dmesg "random: crng init done"). This can take up to three minutes (!) on my machine, as there is not much entropy available (no hardware RNG, network VPN is also waiting for random). Unfortuna...

...if (0 < ret) > > len += ret; > > } while ((0 < ret || EINTR == errno || ERESTART == errno) > > && buflen > len); > > Unless there is a documentation error, the same is required when using > getrandom(). It can also return short as well as to be interrupted. > > regards, > Nikos I am aware that (according to the documentation) both random(4) and getrandom(2) may not return the full size of the read. However, that is (as far as I know) not relevant to the point that I am making. What...

...via dovecot <dovecot at dovecot.org> wrote: > > > On Tue, Mar 05, 2019 at 05:39:28PM +0100, Axel Burri via dovecot wrote: > > Hello > > > > When booting from a slow machine, I can observe dovecot blocking the > > whole boot process. I traced it down to the getrandom() system call in > > lib/randgen.c, which blocks until the random number generator is > > initialized (dmesg "random: crng init done"). This can take up to three > > minutes (!) on my machine, as there is not much entropy available (no > > hardware RNG, network VPN...

On Fri, Jul 29, 2016 at 01:31:14PM -0400, Alex Xu wrote: > > My understanding was that all three methods of obtaining entropy from > userspace all receive data from the CSPRNG in the kernel, and that the > only difference is that /dev/random and getrandom may block depending > on the kernel's estimate of the currently available entropy. This is incorrect. /dev/random is a legacy interface which dates back to a time when people didn't have as much trust in the cryptographic primitives --- when there was concerns that the NSA might have p...

On Fri, Jul 29, 2016 at 01:31:14PM -0400, Alex Xu wrote: > > My understanding was that all three methods of obtaining entropy from > userspace all receive data from the CSPRNG in the kernel, and that the > only difference is that /dev/random and getrandom may block depending > on the kernel's estimate of the currently available entropy. This is incorrect. /dev/random is a legacy interface which dates back to a time when people didn't have as much trust in the cryptographic primitives --- when there was concerns that the NSA might have p...

On Tue, Mar 05, 2019 at 05:39:28PM +0100, Axel Burri via dovecot wrote: > Hello > > When booting from a slow machine, I can observe dovecot blocking the > whole boot process. I traced it down to the getrandom() system call in > lib/randgen.c, which blocks until the random number generator is > initialized (dmesg "random: crng init done"). This can take up to three > minutes (!) on my machine, as there is not much entropy available (no > hardware RNG, network VPN is also waiting for...

...i < atoi(argv[1]); i++) { sleep(1); if ((fd = open("/dev/random", O_RDONLY)) == -1) return 2; if (read(fd, buf, sizeof(buf)) < 1) return 3; if (close(fd) == -1) return 4; } sleep(2); if (syscall(SYS_getrandom, buf, sizeof(buf), 0) == -1) return 5; return 0; } $ qemu-system-x86_64 -nodefaults -machine q35,accel=kvm -nographic -object rng-random,id=rng0,filename=/dev/urandom -device virtio-rng-pci,rng=rng0 -kernel linux-4.7/arch/x86/boot/bzImage -fsdev local,path="$PWD/root",securi...

...i < atoi(argv[1]); i++) { sleep(1); if ((fd = open("/dev/random", O_RDONLY)) == -1) return 2; if (read(fd, buf, sizeof(buf)) < 1) return 3; if (close(fd) == -1) return 4; } sleep(2); if (syscall(SYS_getrandom, buf, sizeof(buf), 0) == -1) return 5; return 0; } $ qemu-system-x86_64 -nodefaults -machine q35,accel=kvm -nographic -object rng-random,id=rng0,filename=/dev/urandom -device virtio-rng-pci,rng=rng0 -kernel linux-4.7/arch/x86/boot/bzImage -fsdev local,path="$PWD/root",securi...

...uli 2016, 18:07:32 CEST schrieb Alex 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 com...

...i, 29 Jul 2016 15:12:30 +0200 Stephan Mueller <smueller at chronox.de> wrote as excerpted: > Am Freitag, 29. Juli 2016, 09:03:45 CEST schrieb Alex Xu: > > In my opinion, assuming I am not doing something terribly wrong, > > this constitutes a bug in the kernel's handling of getrandom calls > > at boot, possibly only when the primary source of entropy is > > virtio. > > Nope, I do not think that this is true: > > - /dev/random returns one byte for one byte of entropy received, but > it has a lower limit of 64 bits > > - getrandom behaves lik...

...3 insertions(+) diff --git a/sandbox-seccomp-filter.c b/sandbox-seccomp-filter.c index b6f6258..846bc08 100644 --- a/sandbox-seccomp-filter.c +++ b/sandbox-seccomp-filter.c @@ -129,6 +129,9 @@ static const struct sock_filter preauth_insns[] = { #else SC_ALLOW(sigprocmask), #endif +#ifdef __NR_getrandom + SC_ALLOW(getrandom), +#endif BPF_STMT(BPF_RET+BPF_K, SECCOMP_FILTER_FAIL), }; -- 2.2.2

...nSSL with an entropy source or re-run configure using one of the --with-prngd-port or --with-prngd-socket options I haven't done anything special in configuring openssl. If I have read the configuration for openssl correctly, with will default to the 'os' source, which I think then is getrandom(2). I think the check in openssh for this is a call to RAND_status(), which is apparently returning a failure. I can't compile without openssl, because I need to allow RSA keys. Any work arounds? Ideas follow. Compile openssh with /dev/urandom as the prngd-socket? Edit the configure script...

On Fri, Sep 19, 2014 at 09:40:42AM -0700, H. Peter Anvin wrote: > > There is a huge disadvantage to the fact that CPUID is a user space > instruction, though. But if the goal is to provide something like getrandom(2) direct from the Host OS, it's not necessarily harmful to allow the Guest ring 3 code to be able to fetch randomness in that way. The hypervisor can implement rate limiting to protect against the guest using this too frequently, but this is something that you should be doing for guest ring 0...