search for: grnd_random

*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 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

...e the same behavior as calling getrandom passing no flags. 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 though, if GRND_RANDOM is passed to getrandom, then it does not hang and returns 1 byte immediately (whether or not GRND_NONBLOCK is set). The following revised program demonstrates this: #include <fcntl.h> #include <linux/random.h> #include <stdlib.h> #include <string.h> #include <syscall.h&...

...random. > > 2. the guest runs getrandom with any requested amount (tested 1 byte > and 16 bytes) and no flags, it blocks for 90-110 seconds while the > "non-blocking pool is initialized". the returned data appears to be > random. > > 3. the guest runs getrandom with GRND_RANDOM with any requested amount, > it returns the desired amount or possibly less, but in my experience at > least 10 bytes. the returned data appears to be random. > > I believe that the difference between cases 1 and 2 is a bug, since > based on my previous statement, in this scenario,...

...random. > > 2. the guest runs getrandom with any requested amount (tested 1 byte > and 16 bytes) and no flags, it blocks for 90-110 seconds while the > "non-blocking pool is initialized". the returned data appears to be > random. > > 3. the guest runs getrandom with GRND_RANDOM with any requested amount, > it returns the desired amount or possibly less, but in my experience at > least 10 bytes. the returned data appears to be random. > > I believe that the difference between cases 1 and 2 is a bug, since > based on my previous statement, in this scenario,...

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

...the screen. the data appears to be random. 2. the guest runs getrandom with any requested amount (tested 1 byte and 16 bytes) and no flags, it blocks for 90-110 seconds while the "non-blocking pool is initialized". the returned data appears to be random. 3. the guest runs getrandom with GRND_RANDOM with any requested amount, it returns the desired amount or possibly less, but in my experience at least 10 bytes. the returned data appears to be random. I believe that the difference between cases 1 and 2 is a bug, since based on my previous statement, in this scenario, getrandom should never bl...

...etrandom 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 though, if GRND_RANDOM is passed to getrandom, > then it does not hang and returns 1 byte immediately (whether or not > GRND_NONBLOCK is set). Sure, because there is one byte in the input_pool at the time user space boots. Note again, /dev/random waits until having 64 bits. > > 1, 2..29: reads all return...

...etrandom 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 though, if GRND_RANDOM is passed to getrandom, > then it does not hang and returns 1 byte immediately (whether or not > GRND_NONBLOCK is set). Sure, because there is one byte in the input_pool at the time user space boots. Note again, /dev/random waits until having 64 bits. > > 1, 2..29: reads all return...