svn commit: r284959 - in head: . share/man/man4 share/man/man9 sys/conf sys/dev/glxsb sys/dev/hifn sys/dev/random sys/dev/rndtest sys/dev/safe sys/dev/syscons sys/dev/ubsec sys/dev/virtio/random sy...

[K. Macy]

I discovered this when I MFC'd and my kernel wouldn't link because of
unresolved symbols. I thought I had put the issue aside when I added
RANDOM_DUMMY to my kernel config.

However, I just hit this:

        while (!random_alg_context.ra_seeded()) {
                if (nonblock) {
                        error = EWOULDBLOCK;
                        break;
                }
                tsleep(&random_alg_context, 0, "randseed", hz/10);
                /* keep tapping away at the pre-read until we seed/unblock. */
                random_alg_context.ra_pre_read();
                printf("random: %s unblock wait\n", __func__);
        }

My system wouldn't boot because this was endlessly spamming the
console. I don't know what the right default here is. But I can say
that this is not it.

I would also like to observe that a good back of the envelope
per-packet budget is 1000 cycles (stock FreeBSD is much worse than
this - nonetheless it is a reasonable figure to strive for). Many
drivers will for a variety of reasons allocate mbufs and clusters
separately. This means that if you're harvesting on alloc / free, your
function is being called 4 times per-packet. Let's have a hypothetical
that your function takes 50 cycles* - in this case your entropy
collection would be consuming a full 20% of the per-packet budget. At
high-packet rates your entropy is likely to be caused more by
indeterminacy of cache misses and lock contention than any true
randomness in the arrival rate.


* It may be less, it may be much more.


I'm not sure where the workflow fell short in this instance, but I'm
inclined to believe that this could have been handled better.

-K



On Thu, Jul 16, 2015 at 11:29 AM, Mark R V Murray <markm at freebsd.org> wrote:
>
>> On 16 Jul 2015, at 15:08, Ian Lepore <ian at FreeBSD.org> wrote:
>>
>> On Thu, 2015-07-16 at 06:39 +0100, Mark Murray wrote:
>>>> On 15 Jul 2015, at 23:43, Adrian Chadd <adrian.chadd at gmail.com> wrote:
>>>>
>>>>> - Add harvesting of slab allocator events. This needs to be checked for
>>>>>   weighing down the allocator code.
>>>>
>>>> Hi,
>>>>
>>>> Is this really doing it upon every one of those events? eg, for each
>>>> mbuf alloc through UMA?
>>>
>>> Only if you turn it on!
>>>
>>> M
>>>
>>
>> In random_harvestq_init() I see
>>
>> harvest_context.hc_source_mask = RANDOM_HARVEST_EVERYTHING_MASK;
>>
>> and
>>
>> #define RANDOM_HARVEST_EVERYTHING_MASK ((1 << (RANDOM_ENVIRONMENTAL_END
>> + 1)) - 1)
>>
>> So doesn't that include the RANDOM_FAST flag that controls harvesting
>> during every UMA alloc and free call?  And that harvesting appears to be
>> anything but fast, at least at a glance... it looks like it passes the
>> entire struct uma_zone to the jenkins hash function... is there really
>> useful entropy in all the data in that struct?
>
> Well spotted, but fear not. All sources are on at startup, and this
> is to ensure that the generator has maximal access to entropy while
> booting.
>
> One of the default duties of etc/rc.d/random is to turn off the UMA
> and ATIME sources. These may be turned on if you want them, but by
> default on the fully booted system they are off.
>
> See ‘sysctl kern.random.harvest.mask_symbolic’ and note that the
> disabled sources are in [].
>
> I have yet to do a full set of benchmarks, but I have discussed
> this with RWatson. A silly benchmark (make world) shows little
> effect, but I will be doing this properly in coming months.
>
> In answer to you final question - yes. The UMA entropy is a bit
> spread out, but it is good.
>
> M
> --
> Mark R V Murray
>
> _______________________________________________
> svn-src-head at freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/svn-src-head
> To unsubscribe, send any mail to "svn-src-head-unsubscribe at freebsd.org"