Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 24 Jul 2015 23:06:59 -0600
From:      Scott Long <scott4long@yahoo.com>
To:        Mark R V Murray <markm@FreeBSD.org>
Cc:        John-Mark Gurney <jmg@funkthat.com>, src-committers <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:  <96EA33AB-7325-4DD2-83F4-B4FAF6F47CB5@yahoo.com>
In-Reply-To: <BC734D25-375C-4C1C-BA8A-BD91158B6A39@FreeBSD.org>
References:  <201506301700.t5UH0jPq001498@svn.freebsd.org> <alpine.BSF.2.20.1507221138360.1071@desktop> <FFAED695-145A-45F5-988D-B843EF5F544B@FreeBSD.org> <alpine.BSF.2.20.1507221249120.1071@desktop> <FFFB06D7-164B-40B3-AFC3-A6630BCF074E@bsdimp.com> <E20B169F-4C8A-4D11-9853-5C2EFC116450@FreeBSD.org> <F54A96A8-D9AD-409A-814F-538B6AD3CD50@yahoo.com> <20150724012519.GE78154@funkthat.com> <BC734D25-375C-4C1C-BA8A-BD91158B6A39@FreeBSD.org>

next in thread | previous in thread | raw e-mail | index | archive | help

> On Jul 24, 2015, at 12:59 AM, Mark R V Murray <markm@FreeBSD.org> =
wrote:
>=20
>=20
>> On 24 Jul 2015, at 02:25, John-Mark Gurney <jmg@funkthat.com> wrote:
>>=20
>> I would like to point out that the goal of collecting large amounts
>> is starting to fall out of favor, and I happen to agree with the =
likes
>> of djb[1] that we don't need an infinite amount of entropy collected =
by
>> the system.  If the attacker can read out our RNG state, then we are
>> already screwed due to many other vulns.
>=20
> I=E2=80=99m working on a premise of =E2=80=9Ctools, not policy=E2=80=9D.=
 I=E2=80=99d like there to be
> enough harvesting points for the box owner to get the warm fuzzies.
> If they choose to use less, fine by me.
>=20

Sure, and that=E2=80=99s not an unreasonable goal, but the devil is in =
the details.
It=E2=80=99s an unfortunate fact of modern CPU architecture that even =
something
as simple and innocent as a run-time control that checks a variable can
cause significant performance problems, thanks to the penalty of cache
misses and bus contention between lots of CPU cores.  Maybe these
=E2=80=9Cextended=E2=80=9D collection points should be controlled with a =
compile-time
option?

>> Many of the issues that FreeBSD sees with lack of entropy at start up
>> is more of a problem on how systems are installed and provisioned.  I
>> don't believe that we currently store any entropy from the install
>> process, yet this is one of the best places to get it, the user is
>> banging on keyboard selecting options, etc.  If an image is designed
>> to be cloned (vm images or appliance images) we need to have a
>> mechanism to ensure that before we start, we get the entropy from
>> other sources, be it a hardware RNG or the console.
>=20
> Getting an initial entropy bundle for first boot is high up on my
> TODO list. :-) Patches welcome! We need the usual /entropy (or
> /var/db/entropy/=E2=80=A6 or whatever) and crucially we need =
/boot/entropy
> and the correct invocation in /boot/loader.conf.
>=20

I agree that bootstrap entropy is a big deal, especially with the =
increasing
prevalence of using virtual machine containers, cloned images, and
datacenter automation.  Addressing that is an interesting problem, and
goes well beyond the scope of in-kernel entropy collection.  I wish I =
had
a simple answer or a patch for you ;-)

>> I would like to see us scale back the entropy collection, and replace
>> it with something like scan the zone once an hour or something
>> similar.  Or do something dtrace style, where we nop/jmp the
>> collection after we feel that the system has collected enough.
>=20
> Most of the current entropy gathering is just about invisible
> anyway. I think the above goes too far, but may be a useful way
> of enabling/disabling (say) UMA gathering on the fly.
>=20
>> Heck, piping in mic data to /dev/random is a good way to seed the
>> rng on many machines.
>=20
> Well, sure, but what if you don=E2=80=99t have microphone? I want lots
> of choices, in anticipation of only a subset being usable.
>=20

I still think that for most use cases where you have a high likelyhood
of draining /dev/random of useful bits, you=E2=80=99re likely already on =
a tight
budget for CPU cycles and you=E2=80=99ll probably just look to a =
hardware
accelerator rather than sacrifice even more CPU cycles.  At least,
that=E2=80=99s what the nice sale people at Cavium and Intel tell me ;-)

Scott




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?96EA33AB-7325-4DD2-83F4-B4FAF6F47CB5>