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

[Mark R V Murray]

> 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’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?