Skip site navigation (1)Skip section navigation (2)
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>