On Wed, 27 Mar 2019 at 14:32:55 -0400, Hannes Frederic Sowa wrote:
> On Tue, Mar 26, 2019, at 20:07, George Spelvin wrote:
>> On Tue, 26 Mar 2019 at 14:03:55 -0400, Hannes Frederic Sowa wrote:
>>> Are you trying to fix the modulo biases? I think that prandom_u32_max
>>> also has bias, would that be
On Tue, Mar 26, 2019, at 20:07, George Spelvin wrote:
> On Tue, 26 Mar 2019 at 14:03:55 -0400, Hannes Frederic Sowa wrote:
> > On Tue, Mar 26, 2019, at 12:10, George Spelvin wrote:
> > The conversation definitely makes sense.
>
> I also fixed the seeding of prandom; it now uses the
> random_ready_
On Tue, 26 Mar 2019 19:07:01 GMT
George Spelvin wrote:
> lfsr113 is indeed trivial to predict. It's a 113-bit LFSR defined
> by a degree-113 polynomial. (The implementation as four separate
> polynomials of degree 31, 29, 28 and 25 doesn't change this.) Given
> any 113 bits of its output (not
On Tue, 26 Mar 2019 at 14:03:55 -0400, Hannes Frederic Sowa wrote:
> On Tue, Mar 26, 2019, at 12:10, George Spelvin wrote:
> The conversation definitely makes sense.
I also fixed the seeding of prandom; it now uses the
random_ready_callback system for seeding.
> Are you trying to fix the modulo b
Hi,
On Tue, Mar 26, 2019, at 12:10, George Spelvin wrote:
> I started on a project to correct all of the instances of
> "prandom_u32() % FOO" in the kernel (there are lots)
> to "prandom_u32_max(FOO)".
The conversation definitely makes sense.
Are you trying to fix the modulo biases? I think that
> A little backstory. I started the prandom_32 stuff long ago when I wanted
> a better (longer period) PRNG for use in netem. Took the existing code from
> older version of GNU scientific library (pre GPLv3). If there is something
> faster with better properties go for it. But the whole point of
On Tue, 26 Mar 2019 11:10:15 GMT
George Spelvin wrote:
> I started on a project to correct all of the instances of
> "prandom_u32() % FOO" in the kernel (there are lots)
> to "prandom_u32_max(FOO)".
>
> This has snowballed into an ongoing audit of random number use in the
> kernel, including use
Apologies... I severely mangled the headers in the previous
message, feeding "Daniel Borkmann " to a
parser which split on whitespace and thought that was three separate
recipients. :-(
To limit the damage, please either reply to *this* message or trim the
headers manually. Sorry about that.
I started on a project to correct all of the instances of
"prandom_u32() % FOO" in the kernel (there are lots)
to "prandom_u32_max(FOO)".
This has snowballed into an ongoing audit of random number use in the
kernel, including uses of get_random_bytes() when get_random_u32 or
prandom_u32() would su
