> On Jul 22, 2015, at 4:53 PM, Jeff Roberson <jrober...@jroberson.net> wrote: > > 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.
I’m not sure I’m happy about this answer. Do you have some research backing up such cavalier claims? >>> 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. A certain video streaming company will be pushing the envelope to get to 100Gbps very soon. Even a few extra instructions on every packet / allocation will be a killer. Especially if one is an almost guaranteed cache miss. This most certainly will be burdensome. There absolutely must be a way to turn this off at compile time. We don’t care that much about entropy to leave performance on the table. Warner
signature.asc
Description: Message signed with OpenPGP using GPGMail
