On Wed, 22 Jul 2015, Mark R V Murray wrote:
On 22 Jul 2015, at 22:42, Jeff Roberson <jrober...@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?
_______________________________________________
svn-src-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
