locks and kernel randomness...

classic Classic list List threaded Threaded
56 messages Options
123
Reply | Threaded
Open this post in threaded view
|

locks and kernel randomness...

John-Mark Gurney-2
I'm working on simplifying kernel randomness interfaces.  I would like
to get read of all weak random generators, and this means replacing
read_random and random(9) w/ effectively arc4rand(9) (to be replaced
by ChaCha or Keccak in the future).

The issue is that random(9) is called from any number of contexts, such
as the scheduler.  This makes locking a bit more interesting.  Currently,
both arc4rand(9) and yarrow/fortuna use a default mtx lock to protect
their state.  This obviously isn't compatible w/ the scheduler, and
possibly other calling contexts.

I have a patch[1] that unifies the random interface.  It converts a few
of the locks from mtx default to mtx spin to deal w/ this.

If/when this is accepted, my next plan is to convert away from arc4rand,
to either ChaCha or Keccak.  I already have another patch that converts
arc4rand and friends over to ChaCha.  This patch does use PCPU data
and sched_pin to help eliminate locks, but this does need more study.
We could either do a restartable loop (but there might be too much state
to safely do) or a critical section (though running chacha a bunch of
times could have impact).

[1] https://reviews.freebsd.org/D1956

--
  John-Mark Gurney Voice: +1 415 225 5579

     "All that I will do, has been done, All that I have, has not."
_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: locks and kernel randomness...

Konstantin Belousov
On Mon, Feb 23, 2015 at 05:20:26PM -0800, John-Mark Gurney wrote:

> I'm working on simplifying kernel randomness interfaces.  I would like
> to get read of all weak random generators, and this means replacing
> read_random and random(9) w/ effectively arc4rand(9) (to be replaced
> by ChaCha or Keccak in the future).
>
> The issue is that random(9) is called from any number of contexts, such
> as the scheduler.  This makes locking a bit more interesting.  Currently,
> both arc4rand(9) and yarrow/fortuna use a default mtx lock to protect
> their state.  This obviously isn't compatible w/ the scheduler, and
> possibly other calling contexts.
>
> I have a patch[1] that unifies the random interface.  It converts a few
> of the locks from mtx default to mtx spin to deal w/ this.
This is definitely an overkill. The rebalancing minor use of randomness
absolutely does not require cryptographical-strenght randomness to
select a moment to rebalance thread queue. Imposing the spin lock on
the whole random machinery just to allow the same random gathering code
to be used for balance_ticks is detriment to the system responsivness.
Scheduler is fine even with congruential generators, as you could see in
the cpu_search(), look for the '69069'.

Please do not enforce yet another spinlock for the system.
_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: locks and kernel randomness...

Harrison Grundy


On 02/23/15 17:57, Konstantin Belousov wrote:

> On Mon, Feb 23, 2015 at 05:20:26PM -0800, John-Mark Gurney wrote:
>> I'm working on simplifying kernel randomness interfaces.  I would
>> like to get read of all weak random generators, and this means
>> replacing read_random and random(9) w/ effectively arc4rand(9)
>> (to be replaced by ChaCha or Keccak in the future).
>>
>> The issue is that random(9) is called from any number of
>> contexts, such as the scheduler.  This makes locking a bit more
>> interesting.  Currently, both arc4rand(9) and yarrow/fortuna use
>> a default mtx lock to protect their state.  This obviously isn't
>> compatible w/ the scheduler, and possibly other calling
>> contexts.
>>
>> I have a patch[1] that unifies the random interface.  It converts
>> a few of the locks from mtx default to mtx spin to deal w/ this.
> This is definitely an overkill. The rebalancing minor use of
> randomness absolutely does not require cryptographical-strenght
> randomness to select a moment to rebalance thread queue. Imposing
> the spin lock on the whole random machinery just to allow the same
> random gathering code to be used for balance_ticks is detriment to
> the system responsivness. Scheduler is fine even with congruential
> generators, as you could see in the cpu_search(), look for the
> '69069'.
>
> Please do not enforce yet another spinlock for the system.
> _______________________________________________

The patch attached to
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=197922 switches
sched_balance to use get_cyclecount, which is also a suitable source
of entropy for this purpose.

It would also be possible to make the scheduler deterministic here,
using cpuid or some such thing to make sure all CPUs don't fire the
balancer at the same time.

--- Harrison
_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: locks and kernel randomness...

John-Mark Gurney-2
In reply to this post by Konstantin Belousov
Konstantin Belousov wrote this message on Tue, Feb 24, 2015 at 03:57 +0200:

> On Mon, Feb 23, 2015 at 05:20:26PM -0800, John-Mark Gurney wrote:
> > I'm working on simplifying kernel randomness interfaces.  I would like
> > to get read of all weak random generators, and this means replacing
> > read_random and random(9) w/ effectively arc4rand(9) (to be replaced
> > by ChaCha or Keccak in the future).
> >
> > The issue is that random(9) is called from any number of contexts, such
> > as the scheduler.  This makes locking a bit more interesting.  Currently,
> > both arc4rand(9) and yarrow/fortuna use a default mtx lock to protect
> > their state.  This obviously isn't compatible w/ the scheduler, and
> > possibly other calling contexts.
> >
> > I have a patch[1] that unifies the random interface.  It converts a few
> > of the locks from mtx default to mtx spin to deal w/ this.
> This is definitely an overkill. The rebalancing minor use of randomness
> absolutely does not require cryptographical-strenght randomness to
> select a moment to rebalance thread queue. Imposing the spin lock on
> the whole random machinery just to allow the same random gathering code
> to be used for balance_ticks is detriment to the system responsivness.
> Scheduler is fine even with congruential generators, as you could see in
> the cpu_search(), look for the '69069'.

Then why doesn't it use this then?  This is exactly why I don't want
random to be a congruential generator... If you're so sure that you
don't need cryptographic secure and that it's a performance benefit
to do so, then you're free to roll your own, but almost all of the
time, code won't meet both requirements.

I haven't audited all the places where random is currently being called
that might require not sleeping.  The scheduler happens to be the first
one I ran into...

> Please do not enforce yet another spinlock for the system.

I sent this email asking for help for how to avoid a spin lock.  I'd
appreciate if you could suggest how to improve my patch.

Thanks.

--
  John-Mark Gurney Voice: +1 415 225 5579

     "All that I will do, has been done, All that I have, has not."
_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: locks and kernel randomness...

Harrison Grundy


On 02/23/15 18:09, John-Mark Gurney wrote:

> Konstantin Belousov wrote this message on Tue, Feb 24, 2015 at
> 03:57 +0200:
>> On Mon, Feb 23, 2015 at 05:20:26PM -0800, John-Mark Gurney
>> wrote:
>>> I'm working on simplifying kernel randomness interfaces.  I
>>> would like to get read of all weak random generators, and this
>>> means replacing read_random and random(9) w/ effectively
>>> arc4rand(9) (to be replaced by ChaCha or Keccak in the
>>> future).
>>>
>>> The issue is that random(9) is called from any number of
>>> contexts, such as the scheduler.  This makes locking a bit more
>>> interesting.  Currently, both arc4rand(9) and yarrow/fortuna
>>> use a default mtx lock to protect their state.  This obviously
>>> isn't compatible w/ the scheduler, and possibly other calling
>>> contexts.
>>>
>>> I have a patch[1] that unifies the random interface.  It
>>> converts a few of the locks from mtx default to mtx spin to
>>> deal w/ this.
>> This is definitely an overkill. The rebalancing minor use of
>> randomness absolutely does not require cryptographical-strenght
>> randomness to select a moment to rebalance thread queue. Imposing
>> the spin lock on the whole random machinery just to allow the
>> same random gathering code to be used for balance_ticks is
>> detriment to the system responsivness. Scheduler is fine even
>> with congruential generators, as you could see in the
>> cpu_search(), look for the '69069'.
>
> Then why doesn't it use this then?  This is exactly why I don't
> want random to be a congruential generator... If you're so sure
> that you don't need cryptographic secure and that it's a
> performance benefit to do so, then you're free to roll your own,
> but almost all of the time, code won't meet both requirements.
>
> I haven't audited all the places where random is currently being
> called that might require not sleeping.  The scheduler happens to
> be the first one I ran into...
>
>> Please do not enforce yet another spinlock for the system.
>
> I sent this email asking for help for how to avoid a spin lock.
> I'd appreciate if you could suggest how to improve my patch.
>
> Thanks.
>

It seems to me that "random()" *should* return truly cryptographic
randomness, while some other cheap mechanism (say randomish() or
notrandom()), that explicitly isn't of cryptographic quality should be
used for cases where "Sort of random" is good enough.

This way, developers can actually decide which one they're going to
use and where it's worth the performance cost to get real randomness.
The scheduler doesn't happen to meet the latter case, so it's probably
not a great example case and should be treated differently.

--- Harrison
_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: locks and kernel randomness...

Konstantin Belousov
In reply to this post by Harrison Grundy
On Mon, Feb 23, 2015 at 06:04:12PM -0800, Harrison Grundy wrote:

>
>
> On 02/23/15 17:57, Konstantin Belousov wrote:
> > On Mon, Feb 23, 2015 at 05:20:26PM -0800, John-Mark Gurney wrote:
> >> I'm working on simplifying kernel randomness interfaces.  I would
> >> like to get read of all weak random generators, and this means
> >> replacing read_random and random(9) w/ effectively arc4rand(9)
> >> (to be replaced by ChaCha or Keccak in the future).
> >>
> >> The issue is that random(9) is called from any number of
> >> contexts, such as the scheduler.  This makes locking a bit more
> >> interesting.  Currently, both arc4rand(9) and yarrow/fortuna use
> >> a default mtx lock to protect their state.  This obviously isn't
> >> compatible w/ the scheduler, and possibly other calling
> >> contexts.
> >>
> >> I have a patch[1] that unifies the random interface.  It converts
> >> a few of the locks from mtx default to mtx spin to deal w/ this.
> > This is definitely an overkill. The rebalancing minor use of
> > randomness absolutely does not require cryptographical-strenght
> > randomness to select a moment to rebalance thread queue. Imposing
> > the spin lock on the whole random machinery just to allow the same
> > random gathering code to be used for balance_ticks is detriment to
> > the system responsivness. Scheduler is fine even with congruential
> > generators, as you could see in the cpu_search(), look for the
> > '69069'.
> >
> > Please do not enforce yet another spinlock for the system.
> > _______________________________________________
>
> The patch attached to
> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=197922 switches
> sched_balance to use get_cyclecount, which is also a suitable source
> of entropy for this purpose.
>
> It would also be possible to make the scheduler deterministic here,
> using cpuid or some such thing to make sure all CPUs don't fire the
> balancer at the same time.
>

The patch in the PR is probably in the right direction, but might be too
simple, unless somebody dispel my fallacy. I remember seeing claims that
on the very low-end embedded devices the get_cyclecount() method may
be non-functional, i.e. returning some constant, probably 0. I somehow
associate MIPS arch with this bias.
_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: locks and kernel randomness...

John-Mark Gurney-2
Konstantin Belousov wrote this message on Tue, Feb 24, 2015 at 04:42 +0200:

> On Mon, Feb 23, 2015 at 06:04:12PM -0800, Harrison Grundy wrote:
> >
> >
> > On 02/23/15 17:57, Konstantin Belousov wrote:
> > > On Mon, Feb 23, 2015 at 05:20:26PM -0800, John-Mark Gurney wrote:
> > >> I'm working on simplifying kernel randomness interfaces.  I would
> > >> like to get read of all weak random generators, and this means
> > >> replacing read_random and random(9) w/ effectively arc4rand(9)
> > >> (to be replaced by ChaCha or Keccak in the future).
> > >>
> > >> The issue is that random(9) is called from any number of
> > >> contexts, such as the scheduler.  This makes locking a bit more
> > >> interesting.  Currently, both arc4rand(9) and yarrow/fortuna use
> > >> a default mtx lock to protect their state.  This obviously isn't
> > >> compatible w/ the scheduler, and possibly other calling
> > >> contexts.
> > >>
> > >> I have a patch[1] that unifies the random interface.  It converts
> > >> a few of the locks from mtx default to mtx spin to deal w/ this.
> > > This is definitely an overkill. The rebalancing minor use of
> > > randomness absolutely does not require cryptographical-strenght
> > > randomness to select a moment to rebalance thread queue. Imposing
> > > the spin lock on the whole random machinery just to allow the same
> > > random gathering code to be used for balance_ticks is detriment to
> > > the system responsivness. Scheduler is fine even with congruential
> > > generators, as you could see in the cpu_search(), look for the
> > > '69069'.
> > >
> > > Please do not enforce yet another spinlock for the system.
> > > _______________________________________________
> >
> > The patch attached to
> > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=197922 switches
> > sched_balance to use get_cyclecount, which is also a suitable source
> > of entropy for this purpose.
> >
> > It would also be possible to make the scheduler deterministic here,
> > using cpuid or some such thing to make sure all CPUs don't fire the
> > balancer at the same time.
> >
>
> The patch in the PR is probably in the right direction, but might be too
> simple, unless somebody dispel my fallacy. I remember seeing claims that
> on the very low-end embedded devices the get_cyclecount() method may
> be non-functional, i.e. returning some constant, probably 0. I somehow
> associate MIPS arch with this bias.

Well, the docs say:
     The speed and the maximum value of each counter is CPU-dependent.  Some
     CPUs (such as the Intel 80486) do not have such a register, so
     get_cyclecount() on these platforms returns a (monotonic) combination of
     numbers represented by the structure returned by binuptime(9).

The clang builtin of cycle counter is documented as returning 0 when
it isn't available.

--
  John-Mark Gurney Voice: +1 415 225 5579

     "All that I will do, has been done, All that I have, has not."
_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: locks and kernel randomness...

Harrison Grundy
In reply to this post by Konstantin Belousov


On 02/23/15 18:42, Konstantin Belousov wrote:

> On Mon, Feb 23, 2015 at 06:04:12PM -0800, Harrison Grundy wrote:
>>
>>
>> On 02/23/15 17:57, Konstantin Belousov wrote:
>>> On Mon, Feb 23, 2015 at 05:20:26PM -0800, John-Mark Gurney wrote:
>>>> I'm working on simplifying kernel randomness interfaces.  I would
>>>> like to get read of all weak random generators, and this means
>>>> replacing read_random and random(9) w/ effectively arc4rand(9)
>>>> (to be replaced by ChaCha or Keccak in the future).
>>>>
>>>> The issue is that random(9) is called from any number of
>>>> contexts, such as the scheduler.  This makes locking a bit more
>>>> interesting.  Currently, both arc4rand(9) and yarrow/fortuna use
>>>> a default mtx lock to protect their state.  This obviously isn't
>>>> compatible w/ the scheduler, and possibly other calling
>>>> contexts.
>>>>
>>>> I have a patch[1] that unifies the random interface.  It converts
>>>> a few of the locks from mtx default to mtx spin to deal w/ this.
>>> This is definitely an overkill. The rebalancing minor use of
>>> randomness absolutely does not require cryptographical-strenght
>>> randomness to select a moment to rebalance thread queue. Imposing
>>> the spin lock on the whole random machinery just to allow the same
>>> random gathering code to be used for balance_ticks is detriment to
>>> the system responsivness. Scheduler is fine even with congruential
>>> generators, as you could see in the cpu_search(), look for the
>>> '69069'.
>>>
>>> Please do not enforce yet another spinlock for the system.
>>> _______________________________________________
>>
>> The patch attached to
>> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=197922 switches
>> sched_balance to use get_cyclecount, which is also a suitable source
>> of entropy for this purpose.
>>
>> It would also be possible to make the scheduler deterministic here,
>> using cpuid or some such thing to make sure all CPUs don't fire the
>> balancer at the same time.
>>
>
> The patch in the PR is probably in the right direction, but might be too
> simple, unless somebody dispel my fallacy. I remember seeing claims that
> on the very low-end embedded devices the get_cyclecount() method may
> be non-functional, i.e. returning some constant, probably 0. I somehow
> associate MIPS arch with this bias.
>

Talking to some of the arm and MIPS developers, it appears
get_cyclecount() may be slow on some older ARM hardware... (In
particular, hardware that doesn't support SMP anyway.)

However, after a quick test on some machines here, I don't think this
function actually needs randomness, due to the large number of other
pathways ULE uses to balance load.

New patch attached to the PR that simply removes the randomness entirely.
_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: locks and kernel randomness...

Bruce Evans-4
In reply to this post by John-Mark Gurney-2
On Mon, 23 Feb 2015, John-Mark Gurney wrote:

> Konstantin Belousov wrote this message on Tue, Feb 24, 2015 at 04:42 +0200:
>> On Mon, Feb 23, 2015 at 06:04:12PM -0800, Harrison Grundy wrote:
>>>
>>> The patch attached to
>>> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=197922 switches
>>> sched_balance to use get_cyclecount, which is also a suitable source
>>> of entropy for this purpose.
>>>
>>> It would also be possible to make the scheduler deterministic here,
>>> using cpuid or some such thing to make sure all CPUs don't fire the
>>> balancer at the same time.
>>
>> The patch in the PR is probably in the right direction, but might be too
>> simple, unless somebody dispel my fallacy. I remember seeing claims that
>> on the very low-end embedded devices the get_cyclecount() method may
>> be non-functional, i.e. returning some constant, probably 0. I somehow
>> associate MIPS arch with this bias.

mips seems to use only a hardware cycle counter now.  This is obfuscated
by spelling the function name as mips_rd_ ## count in its implementation.

The only arch with a very slow get_cyclecount() now seem to be i386 without
a TSC and arm (some cases).

> Well, the docs say:
>     The speed and the maximum value of each counter is CPU-dependent.  Some
>     CPUs (such as the Intel 80486) do not have such a register, so
>     get_cyclecount() on these platforms returns a (monotonic) combination of
>     numbers represented by the structure returned by binuptime(9).

The docs are wrong of course.  Almost as bad as the design of this function.
arm now does:

X #ifdef _KERNEL
X #if __ARM_ARCH >= 6
X #include <machine/cpu-v6.h>
X #endif
X static __inline uint64_t
X get_cyclecount(void)
X {
X #if __ARM_ARCH >= 6
X return cp15_pmccntr_get();
X #else /* No performance counters, so use binuptime(9). This is slooooow */
X struct bintime bt;
X
X binuptime(&bt);
X return ((uint64_t)bt.sec << 56 | bt.frac >> 8);
X #endif
X }
X #endif

Versions used to return the highly non-monotonic (bt.sec ^ bt_frac).
This was best for randomness.  But get_cyclecount() was often abused
for timestamps.  So arm now does the above.  It is still non-monotonic.
It wraps every 256 seconds.  It discards noise in the lower 8 bits of
bt.frac to keep predictable values in the bt.sec.  The noise is often
0, but may contain fairly predictable values from ntpd adjustments.

i386 now uses cpu_ticks().  This partly defeats one of the excuses for
the existence of get_cyclecount().  Using binuptime() directly instead
of get_cyclecount() micro-optimized to an inline rdtsc would have cost
a whole extra 10-20 cycles on modern x86.  Using cpu_ticks() directly
restores some of this cost.  In the best case, rdtsc is now 2 function
calls away (1 indirect: call cpu_ticks(), then an indirect call to
rdtsc()).  The costs of these things on (old) Athlon64 are:

     inline rdtsc: 13 cycles counting loop overhead
     add 1 direct function call: +5 cycles
     add another function call: direct +12 cycles; indirect +10 cycles

28 cycles for a function like cpu_ticks().  IIRC, binuptime() took
58 cycles on (older) AthlonXP.

Newer x86 and maybe Intel instead of AMD changes these times significantly.
Intel rdtsc always seemed to be slower than AMD rdtsc.  Synchronization
for P-state invariance is expensive.  So rdtc on newer x86 takes 40-70
cycles.  The extras for timecounters are more in the noise.  Something
like 90-100 cycles total, with slightly more than half for hardware.

When the TSC is not available, cpu_ticks() may use another cputicker,
but usually there is none, since if there is a cputicker then it is
a TSC by another name, and cpu_ticks uses a timecounter.  It doesn't
do this in the safe way using binuptime(), but returns the hardware
timecount with racy adjustments for monotonicity.  It has to read the
hardware timecounter, and that is the slow part.  So this method is
only used in cases where it is too slow to use.

Apart from its implementation bugs, cpu_ticks() is better than the
special adjustment for arm.

get_cyclecount() is abused for timestamps in de, ktr and sctp.  There
is no support for converting these "timestamps" to human-readable
values even in the easy case where get_cyclecount() returns a monotonic
counter.  The network places should just use binuptime().  ktr shouldn't
do that, and is probably broken in at least some cases where it does
do that via get_cyclecount() using the hardware timecounter.

Bruce
_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: locks and kernel randomness...

Konstantin Belousov
In reply to this post by Harrison Grundy
On Mon, Feb 23, 2015 at 08:36:44PM -0800, Harrison Grundy wrote:

>
>
> On 02/23/15 18:42, Konstantin Belousov wrote:
> > On Mon, Feb 23, 2015 at 06:04:12PM -0800, Harrison Grundy wrote:
> >>
> >>
> >> On 02/23/15 17:57, Konstantin Belousov wrote:
> >>> On Mon, Feb 23, 2015 at 05:20:26PM -0800, John-Mark Gurney wrote:
> >>>> I'm working on simplifying kernel randomness interfaces.  I would
> >>>> like to get read of all weak random generators, and this means
> >>>> replacing read_random and random(9) w/ effectively arc4rand(9)
> >>>> (to be replaced by ChaCha or Keccak in the future).
> >>>>
> >>>> The issue is that random(9) is called from any number of
> >>>> contexts, such as the scheduler.  This makes locking a bit more
> >>>> interesting.  Currently, both arc4rand(9) and yarrow/fortuna use
> >>>> a default mtx lock to protect their state.  This obviously isn't
> >>>> compatible w/ the scheduler, and possibly other calling
> >>>> contexts.
> >>>>
> >>>> I have a patch[1] that unifies the random interface.  It converts
> >>>> a few of the locks from mtx default to mtx spin to deal w/ this.
> >>> This is definitely an overkill. The rebalancing minor use of
> >>> randomness absolutely does not require cryptographical-strenght
> >>> randomness to select a moment to rebalance thread queue. Imposing
> >>> the spin lock on the whole random machinery just to allow the same
> >>> random gathering code to be used for balance_ticks is detriment to
> >>> the system responsivness. Scheduler is fine even with congruential
> >>> generators, as you could see in the cpu_search(), look for the
> >>> '69069'.
> >>>
> >>> Please do not enforce yet another spinlock for the system.
> >>> _______________________________________________
> >>
> >> The patch attached to
> >> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=197922 switches
> >> sched_balance to use get_cyclecount, which is also a suitable source
> >> of entropy for this purpose.
> >>
> >> It would also be possible to make the scheduler deterministic here,
> >> using cpuid or some such thing to make sure all CPUs don't fire the
> >> balancer at the same time.
> >>
> >
> > The patch in the PR is probably in the right direction, but might be too
> > simple, unless somebody dispel my fallacy. I remember seeing claims that
> > on the very low-end embedded devices the get_cyclecount() method may
> > be non-functional, i.e. returning some constant, probably 0. I somehow
> > associate MIPS arch with this bias.
> >
>
> Talking to some of the arm and MIPS developers, it appears
> get_cyclecount() may be slow on some older ARM hardware... (In
> particular, hardware that doesn't support SMP anyway.)
>
> However, after a quick test on some machines here, I don't think this
> function actually needs randomness, due to the large number of other
> pathways ULE uses to balance load.
Well, system does benefit from some irregularity in a scheduler.
It is in fact required for locks to work.

>
> New patch attached to the PR that simply removes the randomness entirely.

Since my groundless worries about get_cyclecount() were defeated,
I think your first patch is fine and is the way to go.
_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: locks and kernel randomness...

Warner Losh
In reply to this post by Konstantin Belousov

> On Feb 23, 2015, at 7:42 PM, Konstantin Belousov <[hidden email]> wrote:
>
> On Mon, Feb 23, 2015 at 06:04:12PM -0800, Harrison Grundy wrote:
>>
>>
>> On 02/23/15 17:57, Konstantin Belousov wrote:
>>> On Mon, Feb 23, 2015 at 05:20:26PM -0800, John-Mark Gurney wrote:
>>>> I'm working on simplifying kernel randomness interfaces.  I would
>>>> like to get read of all weak random generators, and this means
>>>> replacing read_random and random(9) w/ effectively arc4rand(9)
>>>> (to be replaced by ChaCha or Keccak in the future).
>>>>
>>>> The issue is that random(9) is called from any number of
>>>> contexts, such as the scheduler.  This makes locking a bit more
>>>> interesting.  Currently, both arc4rand(9) and yarrow/fortuna use
>>>> a default mtx lock to protect their state.  This obviously isn't
>>>> compatible w/ the scheduler, and possibly other calling
>>>> contexts.
>>>>
>>>> I have a patch[1] that unifies the random interface.  It converts
>>>> a few of the locks from mtx default to mtx spin to deal w/ this.
>>> This is definitely an overkill. The rebalancing minor use of
>>> randomness absolutely does not require cryptographical-strenght
>>> randomness to select a moment to rebalance thread queue. Imposing
>>> the spin lock on the whole random machinery just to allow the same
>>> random gathering code to be used for balance_ticks is detriment to
>>> the system responsivness. Scheduler is fine even with congruential
>>> generators, as you could see in the cpu_search(), look for the
>>> '69069'.
>>>
>>> Please do not enforce yet another spinlock for the system.
>>> _______________________________________________
>>
>> The patch attached to
>> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=197922 switches
>> sched_balance to use get_cyclecount, which is also a suitable source
>> of entropy for this purpose.
>>
>> It would also be possible to make the scheduler deterministic here,
>> using cpuid or some such thing to make sure all CPUs don't fire the
>> balancer at the same time.
>>
>
> The patch in the PR is probably in the right direction, but might be too
> simple, unless somebody dispel my fallacy. I remember seeing claims that
> on the very low-end embedded devices the get_cyclecount() method may
> be non-functional, i.e. returning some constant, probably 0. I somehow
> associate MIPS arch with this bias.

arm v4/v5 don’t have get_cyclecount() in hardware. It simply doesn’t exist.

However, this patch is only for SMP, which also isn’t available on arm v4/v5
in our tree.

MIPS’ get cycle count, though, has been defined since R4k days and so much
software depends on it, it would surprise me if that was eliminated to save silicon.

Then again, if you want to change random(), provide a weak_random() that’s
the traditional non-crypto thing that’s fast and lockless. That would make it easy
to audit in our tree. The scheduler doesn’t need cryptographic randomness, it
just needs to make different choices sometimes to ensure its notion of fairness.

Warner

_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: locks and kernel randomness...

Warner Losh
In reply to this post by Harrison Grundy

> On Feb 23, 2015, at 9:36 PM, Harrison Grundy <[hidden email]> wrote:
>
>
>
> On 02/23/15 18:42, Konstantin Belousov wrote:
>> On Mon, Feb 23, 2015 at 06:04:12PM -0800, Harrison Grundy wrote:
>>>
>>>
>>> On 02/23/15 17:57, Konstantin Belousov wrote:
>>>> On Mon, Feb 23, 2015 at 05:20:26PM -0800, John-Mark Gurney wrote:
>>>>> I'm working on simplifying kernel randomness interfaces.  I would
>>>>> like to get read of all weak random generators, and this means
>>>>> replacing read_random and random(9) w/ effectively arc4rand(9)
>>>>> (to be replaced by ChaCha or Keccak in the future).
>>>>>
>>>>> The issue is that random(9) is called from any number of
>>>>> contexts, such as the scheduler.  This makes locking a bit more
>>>>> interesting.  Currently, both arc4rand(9) and yarrow/fortuna use
>>>>> a default mtx lock to protect their state.  This obviously isn't
>>>>> compatible w/ the scheduler, and possibly other calling
>>>>> contexts.
>>>>>
>>>>> I have a patch[1] that unifies the random interface.  It converts
>>>>> a few of the locks from mtx default to mtx spin to deal w/ this.
>>>> This is definitely an overkill. The rebalancing minor use of
>>>> randomness absolutely does not require cryptographical-strenght
>>>> randomness to select a moment to rebalance thread queue. Imposing
>>>> the spin lock on the whole random machinery just to allow the same
>>>> random gathering code to be used for balance_ticks is detriment to
>>>> the system responsivness. Scheduler is fine even with congruential
>>>> generators, as you could see in the cpu_search(), look for the
>>>> '69069'.
>>>>
>>>> Please do not enforce yet another spinlock for the system.
>>>> _______________________________________________
>>>
>>> The patch attached to
>>> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=197922 switches
>>> sched_balance to use get_cyclecount, which is also a suitable source
>>> of entropy for this purpose.
>>>
>>> It would also be possible to make the scheduler deterministic here,
>>> using cpuid or some such thing to make sure all CPUs don't fire the
>>> balancer at the same time.
>>>
>>
>> The patch in the PR is probably in the right direction, but might be too
>> simple, unless somebody dispel my fallacy. I remember seeing claims that
>> on the very low-end embedded devices the get_cyclecount() method may
>> be non-functional, i.e. returning some constant, probably 0. I somehow
>> associate MIPS arch with this bias.
>>
>
> Talking to some of the arm and MIPS developers, it appears
> get_cyclecount() may be slow on some older ARM hardware... (In
> particular, hardware that doesn't support SMP anyway.)

It simply doesn’t exist on older ARM hardware. Some SoCs have
something similar to a real-time clock that you can read, but that’s
not reliable for this use.

> However, after a quick test on some machines here, I don't think this
> function actually needs randomness, due to the large number of other
> pathways ULE uses to balance load.
>
> New patch attached to the PR that simply removes the randomness entirely.

Are you sure about that?

Warner

_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: locks and kernel randomness...

Harrison Grundy


On 02/24/15 06:58, Warner Losh wrote:

>
>> On Feb 23, 2015, at 9:36 PM, Harrison Grundy
>> <[hidden email]> wrote:
>>
>>
>>
>> On 02/23/15 18:42, Konstantin Belousov wrote:
>>> On Mon, Feb 23, 2015 at 06:04:12PM -0800, Harrison Grundy
>>> wrote:
>>>>
>>>>
>>>> On 02/23/15 17:57, Konstantin Belousov wrote:
>>>>> On Mon, Feb 23, 2015 at 05:20:26PM -0800, John-Mark Gurney
>>>>> wrote:
>>>>>> I'm working on simplifying kernel randomness interfaces.
>>>>>> I would like to get read of all weak random generators,
>>>>>> and this means replacing read_random and random(9) w/
>>>>>> effectively arc4rand(9) (to be replaced by ChaCha or
>>>>>> Keccak in the future).
>>>>>>
>>>>>> The issue is that random(9) is called from any number of
>>>>>> contexts, such as the scheduler.  This makes locking a
>>>>>> bit more interesting.  Currently, both arc4rand(9) and
>>>>>> yarrow/fortuna use a default mtx lock to protect their
>>>>>> state.  This obviously isn't compatible w/ the scheduler,
>>>>>> and possibly other calling contexts.
>>>>>>
>>>>>> I have a patch[1] that unifies the random interface.  It
>>>>>> converts a few of the locks from mtx default to mtx spin
>>>>>> to deal w/ this.
>>>>> This is definitely an overkill. The rebalancing minor use
>>>>> of randomness absolutely does not require
>>>>> cryptographical-strenght randomness to select a moment to
>>>>> rebalance thread queue. Imposing the spin lock on the whole
>>>>> random machinery just to allow the same random gathering
>>>>> code to be used for balance_ticks is detriment to the
>>>>> system responsivness. Scheduler is fine even with
>>>>> congruential generators, as you could see in the
>>>>> cpu_search(), look for the '69069'.
>>>>>
>>>>> Please do not enforce yet another spinlock for the system.
>>>>>  _______________________________________________
>>>>
>>>> The patch attached to
>>>> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=197922
>>>> switches sched_balance to use get_cyclecount, which is also a
>>>> suitable source of entropy for this purpose.
>>>>
>>>> It would also be possible to make the scheduler deterministic
>>>> here, using cpuid or some such thing to make sure all CPUs
>>>> don't fire the balancer at the same time.
>>>>
>>>
>>> The patch in the PR is probably in the right direction, but
>>> might be too simple, unless somebody dispel my fallacy. I
>>> remember seeing claims that on the very low-end embedded
>>> devices the get_cyclecount() method may be non-functional, i.e.
>>> returning some constant, probably 0. I somehow associate MIPS
>>> arch with this bias.
>>>
>>
>> Talking to some of the arm and MIPS developers, it appears
>> get_cyclecount() may be slow on some older ARM hardware... (In
>> particular, hardware that doesn't support SMP anyway.)
>
> It simply doesn’t exist on older ARM hardware. Some SoCs have
> something similar to a real-time clock that you can read, but
> that’s not reliable for this use.
>
>> However, after a quick test on some machines here, I don't think
>> this function actually needs randomness, due to the large number
>> of other pathways ULE uses to balance load.
>>
>> New patch attached to the PR that simply removes the randomness
>> entirely.
>
> Are you sure about that?

I'm testing on an 8 core AMD Bulldozer machine without any noticable
issues. You could game the scheduler a bit by running near the
"beginning" of the balance interval, but the preemption, idle steal,
and priority recalculation-caused migrations pretty much wipe out the
effect.

That being said, get_cyclecount is pretty cheap, and this code doesn't
run *that* often, so if there's a rare edge case I'm not running into
that benefits from it, I suspect it's worth keeping the... 'faux'
randomness in there somewhere. Anyone else want to test it?

--- Harrison

>
> Warner
>
> _______________________________________________
> [hidden email] mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-arch To
> unsubscribe, send any mail to
> "[hidden email]"
>
_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: locks and kernel randomness...

John-Mark Gurney-2
In reply to this post by Warner Losh
Warner Losh wrote this message on Tue, Feb 24, 2015 at 07:56 -0700:
> Then again, if you want to change random(), provide a weak_random() that???s
> the traditional non-crypto thing that???s fast and lockless. That would make it easy
> to audit in our tree. The scheduler doesn???t need cryptographic randomness, it
> just needs to make different choices sometimes to ensure its notion of fairness.

I do not support having a weak_random...  If the consumer is sure
enough that you don't need a secure random, then they can pick an LCG
and implement it themselves and deal (or not) w/ the locking issues...

It appears that the scheduler had an LCG but for some reason the authors
didn't feel like using it here..

--
  John-Mark Gurney Voice: +1 415 225 5579

     "All that I will do, has been done, All that I have, has not."
_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: locks and kernel randomness...

Alfred Perlstein-2


On 2/24/15 12:40 PM, John-Mark Gurney wrote:

> Warner Losh wrote this message on Tue, Feb 24, 2015 at 07:56 -0700:
>> Then again, if you want to change random(), provide a weak_random() that???s
>> the traditional non-crypto thing that???s fast and lockless. That would make it easy
>> to audit in our tree. The scheduler doesn???t need cryptographic randomness, it
>> just needs to make different choices sometimes to ensure its notion of fairness.
>
> I do not support having a weak_random...  If the consumer is sure
> enough that you don't need a secure random, then they can pick an LCG
> and implement it themselves and deal (or not) w/ the locking issues...
>
> It appears that the scheduler had an LCG but for some reason the authors
> didn't feel like using it here..
>

The way I read this argument is that no low quality sources of
randomness shall be allowed.

So we should get rid of rand(3)?  When do we deprecate that?

Your argument doesn't hold water.

-Alfred
_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: locks and kernel randomness...

Warner Losh
In reply to this post by John-Mark Gurney-2

> On Feb 24, 2015, at 10:40 AM, John-Mark Gurney <[hidden email]> wrote:
>
> Warner Losh wrote this message on Tue, Feb 24, 2015 at 07:56 -0700:
>> Then again, if you want to change random(), provide a weak_random() that???s
>> the traditional non-crypto thing that???s fast and lockless. That would make it easy
>> to audit in our tree. The scheduler doesn???t need cryptographic randomness, it
>> just needs to make different choices sometimes to ensure its notion of fairness.
>
> I do not support having a weak_random...  If the consumer is sure
> enough that you don't need a secure random, then they can pick an LCG
> and implement it themselves and deal (or not) w/ the locking issues...
>
> It appears that the scheduler had an LCG but for some reason the authors
> didn't feel like using it here..

Why don’t you support having a common random routine that’s to mix the
pot, but not cryptographically secure? Lots of algorithms use them, and having
a common one would keep us from reinventing the wheel.

Warner


_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: locks and kernel randomness...

John-Mark Gurney-2
In reply to this post by Alfred Perlstein-2
Alfred Perlstein wrote this message on Tue, Feb 24, 2015 at 13:04 -0500:

> On 2/24/15 12:40 PM, John-Mark Gurney wrote:
> > Warner Losh wrote this message on Tue, Feb 24, 2015 at 07:56 -0700:
> >> Then again, if you want to change random(), provide a weak_random() that???s
> >> the traditional non-crypto thing that???s fast and lockless. That would make it easy
> >> to audit in our tree. The scheduler doesn???t need cryptographic randomness, it
> >> just needs to make different choices sometimes to ensure its notion of fairness.
> >
> > I do not support having a weak_random...  If the consumer is sure
> > enough that you don't need a secure random, then they can pick an LCG
> > and implement it themselves and deal (or not) w/ the locking issues...
> >
> > It appears that the scheduler had an LCG but for some reason the authors
> > didn't feel like using it here..
>
> The way I read this argument is that no low quality sources of
> randomness shall be allowed.

No, I'm saying that the person who needs the predictable randomness
needs to do extra work to get it...  If they care that much about
performance/predictability/etc, then a little extra work won't hurt
them..  And if they don't know what an LCG is, then they aren't
qualified to make the decision that a weaker RNG is correct for their
situation..

> So we should get rid of rand(3)?  When do we deprecate that?

No, we should replace it w/ proper randomness like OpenBSD has...
I'm willing to go that far and I think FreeBSD should...  OpenBSD has
done a lot of leg work in tracking down ports that correctly use
rand(3), and letting them keep their deterministic randomness, while
the remaining get real random..

> Your argument doesn't hold water.

Sorry, you're argument sounds like it's from the 90's when we didn't
know any better on how to make secure systems...  Will you promise to
audit all new uses of randomness in the system to make sure that they
are using the correct, secure API?

Considering that it's been recommended that people NOT use
read_random(9) for 14 years, yet people continue to use it in new code,
demonstrates that people do not know what they are doing (wrt
randomness), and the only way to make sure they do the correct, secure
thing is to only provide the secure API...

--
  John-Mark Gurney Voice: +1 415 225 5579

     "All that I will do, has been done, All that I have, has not."
_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: locks and kernel randomness...

John-Mark Gurney-2
In reply to this post by Warner Losh
Warner Losh wrote this message on Tue, Feb 24, 2015 at 11:03 -0700:

>
> > On Feb 24, 2015, at 10:40 AM, John-Mark Gurney <[hidden email]> wrote:
> >
> > Warner Losh wrote this message on Tue, Feb 24, 2015 at 07:56 -0700:
> >> Then again, if you want to change random(), provide a weak_random() that???s
> >> the traditional non-crypto thing that???s fast and lockless. That would make it easy
> >> to audit in our tree. The scheduler doesn???t need cryptographic randomness, it
> >> just needs to make different choices sometimes to ensure its notion of fairness.
> >
> > I do not support having a weak_random...  If the consumer is sure
> > enough that you don't need a secure random, then they can pick an LCG
> > and implement it themselves and deal (or not) w/ the locking issues...
> >
> > It appears that the scheduler had an LCG but for some reason the authors
> > didn't feel like using it here..
>
> Why don???t you support having a common random routine that???s to mix the
> pot, but not cryptographically secure? Lots of algorithms use them, and having
> a common one would keep us from reinventing the wheel.

Why can't these algorithms use a cryptographically secure RNG instead?
No one has truely answered that point..  Everyone says they want to use
an insecure RNG, but the real question is, why can't/shouldn't these
algorithms use a CSPRNG?

--
  John-Mark Gurney Voice: +1 415 225 5579

     "All that I will do, has been done, All that I have, has not."
_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: locks and kernel randomness...

Harrison Grundy
In reply to this post by John-Mark Gurney-2


On 02/24/15 10:25, John-Mark Gurney wrote:

> Alfred Perlstein wrote this message on Tue, Feb 24, 2015 at 13:04
> -0500:
>> On 2/24/15 12:40 PM, John-Mark Gurney wrote:
>>> Warner Losh wrote this message on Tue, Feb 24, 2015 at 07:56
>>> -0700:
>>>> Then again, if you want to change random(), provide a
>>>> weak_random() that???s the traditional non-crypto thing
>>>> that???s fast and lockless. That would make it easy to audit
>>>> in our tree. The scheduler doesn???t need cryptographic
>>>> randomness, it just needs to make different choices sometimes
>>>> to ensure its notion of fairness.
>>>
>>> I do not support having a weak_random...  If the consumer is
>>> sure enough that you don't need a secure random, then they can
>>> pick an LCG and implement it themselves and deal (or not) w/
>>> the locking issues...
>>>
>>> It appears that the scheduler had an LCG but for some reason
>>> the authors didn't feel like using it here..
>>
>> The way I read this argument is that no low quality sources of
>> randomness shall be allowed.
>
> No, I'm saying that the person who needs the predictable
> randomness needs to do extra work to get it...  If they care that
> much about performance/predictability/etc, then a little extra work
> won't hurt them..  And if they don't know what an LCG is, then they
> aren't qualified to make the decision that a weaker RNG is correct
> for their situation..
>
>> So we should get rid of rand(3)?  When do we deprecate that?
>
> No, we should replace it w/ proper randomness like OpenBSD has...
> I'm willing to go that far and I think FreeBSD should...  OpenBSD
> has done a lot of leg work in tracking down ports that correctly
> use rand(3), and letting them keep their deterministic randomness,
> while the remaining get real random..
>
>> Your argument doesn't hold water.
>
> Sorry, you're argument sounds like it's from the 90's when we
> didn't know any better on how to make secure systems...  Will you
> promise to audit all new uses of randomness in the system to make
> sure that they are using the correct, secure API?
>
> Considering that it's been recommended that people NOT use
> read_random(9) for 14 years, yet people continue to use it in new
> code, demonstrates that people do not know what they are doing
> (wrt randomness), and the only way to make sure they do the
> correct, secure thing is to only provide the secure API...
>

I think a large part of this issue is, in the end, terminology.

Developers call "random()" when they actually mean a whole lot of
different things, from ULE's "I need a number here that changes some
so this value jitters" to "I'm trying to create an OTP to protect this
letter from the NSA and don't have time to break out my geiger counter."

A single function simply won't meet all of these needs. I believe the
default behavior *should* be a CSPRNG, simply so that if someone
hasn't fully considered what they need, their code will still be
"safe" (as far as random numbers go, anyway). That being said, if
someone *has* considered the problem, there is no particular reason to
force them to write yet another implementation of something thousands
of other people have written.

I propose converting random() to be a true, SMP-safe, CSPRNG so that
the default behavior is as secure as possible, and the creation of
"fauxrandom()" (Or some such thing... hopefully someone has a better
name) for those circumstances where one can accept the degradation in
random number randomness, in exchange for a significant performance
improvement. By having both options available, and documenting the
difference between them, we can generally get the best of both worlds.

I don't believe there is a programming solution to solving the problem
of a developer who is wrong also being sure about what sort of
"random" they need.

--- Harrison
_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: locks and kernel randomness...

Ian Lepore-3
In reply to this post by John-Mark Gurney-2
On Tue, 2015-02-24 at 10:30 -0800, John-Mark Gurney wrote:

> Warner Losh wrote this message on Tue, Feb 24, 2015 at 11:03 -0700:
> >
> > > On Feb 24, 2015, at 10:40 AM, John-Mark Gurney <[hidden email]> wrote:
> > >
> > > Warner Losh wrote this message on Tue, Feb 24, 2015 at 07:56 -0700:
> > >> Then again, if you want to change random(), provide a weak_random() that???s
> > >> the traditional non-crypto thing that???s fast and lockless. That would make it easy
> > >> to audit in our tree. The scheduler doesn???t need cryptographic randomness, it
> > >> just needs to make different choices sometimes to ensure its notion of fairness.
> > >
> > > I do not support having a weak_random...  If the consumer is sure
> > > enough that you don't need a secure random, then they can pick an LCG
> > > and implement it themselves and deal (or not) w/ the locking issues...
> > >
> > > It appears that the scheduler had an LCG but for some reason the authors
> > > didn't feel like using it here..
> >
> > Why don???t you support having a common random routine that???s to mix the
> > pot, but not cryptographically secure? Lots of algorithms use them, and having
> > a common one would keep us from reinventing the wheel.
>
> Why can't these algorithms use a cryptographically secure RNG instead?
> No one has truely answered that point..  Everyone says they want to use
> an insecure RNG, but the real question is, why can't/shouldn't these
> algorithms use a CSPRNG?
>

Because of performance.  Not everything needs crypto-strength
randomness.

The problem here is that you are never going to accept the validity of
that statement no matter how many of us complain over and over again
about this kind of thing.  You've got some religion that the rest of us
don't buy into, and you've got it fervently enough that you'll just keep
saying the same mindless things over and over again until we all get
bored and wander away.

And freebsd gets a little more bloated and a little slower and a lot
less able to run on anything except the very fastest hardware that was
just released last week.  Thanks for "improving" it in that way.

-- Ian


_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "[hidden email]"
123