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: >=20 > On Tue, 30 Jun 2015, Mark Murray wrote: >=20 >> - Add harvesting of slab allocator events. This needs to be checked = for >> weighing down the allocator code. >=20 > 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=E2=80=99m not sure I accept that - Fortuna is very careful about using = non-reversible hashing in it=E2=80=99s accumulation, and countering such = degradation is one of the algorithm=E2=80=99s 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=E2=80=99m willing to discuss optimising this, and have plans for some = micro-benchmarks. M --=20 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>