Date: Wed, 22 Jul 2015 22:59:14 +0100 From: Mark R V Murray <markm@FreeBSD.org> To: Jeff Roberson <jroberson@jroberson.net> Cc: src-committers@freebsd.org, svn-src-all@freebsd.org, svn-src-head@freebsd.org Subject: Re: 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... Message-ID: <FFAED695-145A-45F5-988D-B843EF5F544B@FreeBSD.org> In-Reply-To: <alpine.BSF.2.20.1507221138360.1071@desktop> References: <201506301700.t5UH0jPq001498@svn.freebsd.org> <alpine.BSF.2.20.1507221138360.1071@desktop>
next in thread | previous in thread | raw e-mail | index | archive | help
> On 22 Jul 2015, at 22:42, Jeff Roberson <jroberson@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?
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?FFAED695-145A-45F5-988D-B843EF5F544B>