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>