similar to: 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

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

Am Freitag, 29. Juli 2016, 09:03:45 CEST schrieb Alex Xu: Hi Alex, > On Fri, 29 Jul 2016 12:24:27 +0200 > > Nikos Mavrogiannopoulos <nmav at gnutls.org> wrote: > > 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

Am Freitag, 29. Juli 2016, 09:03:45 CEST schrieb Alex Xu: Hi Alex, > On Fri, 29 Jul 2016 12:24:27 +0200 > > Nikos Mavrogiannopoulos <nmav at gnutls.org> wrote: > > 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

On Fri, 29 Jul 2016 12:24:27 +0200 Nikos Mavrogiannopoulos <nmav at gnutls.org> wrote: > 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

Am Donnerstag, 28. Juli 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

Am Freitag, 29. Juli 2016, 10:14:07 CEST schrieb Alex Xu: Hi Alex, > On Fri, 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

Am Freitag, 29. Juli 2016, 10:14:07 CEST schrieb Alex Xu: Hi Alex, > On Fri, 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

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

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

On Fri, 29 Jul 2016 19:03:51 +0200 Stephan Mueller <smueller at chronox.de> wrote as excerpted: > 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

On Fri, 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 >

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

> On 05 March 2019 at 18:51 William Taylor 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,

*SSL libraries or the C library may/will require it. --- sandbox-seccomp-filter.c | 3 +++ 1 file changed, 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

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 >

I'm trying to compile openssh with openssl 3.1 on a linux machine with kernel 4.15.10. I seem to get stuck at: configure: error: OpenSSH has no source of random numbers. Please configure OpenSSL 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

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

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

Hmm, I guess I need a sys::Math::getRandom() function that uses a "good" random number generator on the given platform. I'll make a note of this and tuck it away for future implementation. Reid. Chris Lattner wrote: > On Tue, 28 Sep 2004, Paolo Invernizzi wrote: > > >>The next major problem is that VC has only >> >>int rand(void) >>void srand(