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

[Jeff Roberson]

On Wed, 22 Jul 2015, Mark R V Murray wrote:

>
>> On 22 Jul 2015, at 22:42, Jeff Roberson <jroberson at jroberson.net> wrote:
>>
>> On Tue, 30 Jun 2015, Mark Murray wrote:
>>
>>> - Add harvesting of slab allocator events. This needs to be checked for
>>>   weighing down the allocator code.
>>
>> Neither filesystem operations nor allocations are random events.  They are trivially influenced by user code.  A malicious attacker could create repeated patterns of allocations or filesystem activity through the syscall path to degrade your random sample source.
>
> I?m not sure I accept that - Fortuna is very careful about using 
> non-reversible hashing in it?s accumulation, and countering such 
> degradation is one of the algorithm?s strong points. There is perhaps 
> risk of *no* entropy, but even the per-event timing jitter will be 
> providing this, if nothing else.
>
>> Perhaps more importantly to me, this is an unacceptable performance burden for the allocator.  At a minimum it should compile out by default.  Great care has been taken to reduce the fast path of the allocator to the minimum number of cycles and even cache misses.
>
> As currently set up in etc/rc.d/* by default, there is a simple check at 
> each UMA harvesting opportunity, and no further action. I asked Robert 
> Watson if this was burdensome, and he said it was not.

I find this burdensome.  You can easily add a macro around the calls or 
hide them in an inline with a default to off.  Even a function call that 
checks a global and does nothing else is a handful of new cache misses.  A 
microbenchmark will not realize the full cost of this.  You will instead 
get the dozen or so instructions of overhead which I still find 
objectionable.

Kip's observations about packet cycle budgets in high-performance 
applications are accurate and this is something we have put great care 
into over time.

Thanks,
Jeff

>
> I?m willing to discuss optimising this, and have plans for some 
> micro-benchmarks.
>
> M
> -- 
> Mark R V Murray
>
> PS: Please trim mail when responding - was it necessary to send me back the whole commit message and diff?
>