Re: [PATCH v5 01/13] random: invalidate batched entropy after crng init

On 2017-06-16 14:12:42 [+0200], Jason A. Donenfeld wrote: > I actually figured that out myself after sending the initial email, so > then I wrote a follow-up patch which I attached to this thread. You > should have received it. Can you take a look? replied to the patch. Sebastian

Re: [PATCH v5 01/13] random: invalidate batched entropy after crng init

On Fri, Jun 16, 2017 at 10:31 AM, Sebastian Andrzej Siewior wrote: > am talking about. Again: I actually figured that out myself after sending the initial email, so then I wrote a follow-up patch which I attached to this thread. You should have received it. Can you take

Re: [PATCH v5 01/13] random: invalidate batched entropy after crng init

On 2017-06-15 00:33:12 [+0200], Jason A. Donenfeld wrote: > There's a potential race that I fixed in my v5 of that patch set, but > Ted only took v4, and for whatever reason has been to busy to submit > the additional patch I already posted showing the diff between v4 > Hopefully he actually gets

Re: [PATCH v5 01/13] random: invalidate batched entropy after crng init

There's a potential race that I fixed in my v5 of that patch set, but Ted only took v4, and for whatever reason has been to busy to submit the additional patch I already posted showing the diff between v4 Hopefully he actually gets around to it and sends this for the next rc. Here it is:

Re: [PATCH v5 01/13] random: invalidate batched entropy after crng init

On 2017-06-08 01:25:55 [+0200], Jason A. Donenfeld wrote: > It's possible that get_random_{u32,u64} is used before the crng has > initialized, in which case, its output might not be cryptographically > secure. For this problem, directly, this patch set is introducing the > *_wait variety of

[PATCH v5 01/13] random: invalidate batched entropy after crng init

It's possible that get_random_{u32,u64} is used before the crng has initialized, in which case, its output might not be cryptographically secure. For this problem, directly, this patch set is introducing the *_wait variety of functions, but even with that, there's a subtle issue: what happens to

[PATCH v5 01/13] random: invalidate batched entropy after crng init

It's possible that get_random_{u32,u64} is used before the crng has initialized, in which case, its output might not be cryptographically secure. For this problem, directly, this patch set is introducing the *_wait variety of functions, but even with that, there's a subtle issue: what happens to