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...
Warner Losh
imp at bsdimp.com
Wed Jul 22 23:53:47 UTC 2015
> On Jul 22, 2015, at 4:53 PM, Jeff Roberson <jroberson at jroberson.net> wrote:
>
> 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.
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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 842 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.freebsd.org/pipermail/svn-src-all/attachments/20150722/4fd2459b/attachment.bin>
More information about the svn-src-all
mailing list