From owner-svn-src-all@freebsd.org Sat Jul 25 05:12:48 2015 Return-Path: Delivered-To: svn-src-all@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 643339A953F for ; Sat, 25 Jul 2015 05:12:48 +0000 (UTC) (envelope-from scott4long@yahoo.com) Received: from nm28-vm4.bullet.mail.gq1.yahoo.com (nm28-vm4.bullet.mail.gq1.yahoo.com [98.136.216.163]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 342201C3F for ; Sat, 25 Jul 2015 05:12:48 +0000 (UTC) (envelope-from scott4long@yahoo.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1437800822; bh=nCiiXUgsxJsWsFuE+AJd4w+cGsVUquGLsdoO4Q/wr3c=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject; b=jnyDGSIt8XqVw/PVL4cATKIpRlvwT8c2Qrw96LS/mWve/nEGW1K4iDoeICG1C/49DDWeajmvPOgFEikpkFNN0bfojMY4Khgy14NktlhpxFo2ZXdh5ZPsBToDVd2FR7ik0G2ENlOk1/x3vFwFYv02WuwiA6Xk5Cx8YZwXHTmYeWUaXK5IBhwREX54yjEc+v9hGMfgvaVlWRtgnmgGrsaJwK9k/mD64BM4WU4MhcCBUYNaCDvseB+RWiR+4ZF1Xtq3NXnM+vpjUAlnucHyTZP4ORkaxvtfIV6Jwp/Uxi14/koMsKFNzOO7I+W6PGedUURo4K9OcmVDxRIUgy691j/vjg== Received: from [98.137.12.56] by nm28.bullet.mail.gq1.yahoo.com with NNFMP; 25 Jul 2015 05:07:02 -0000 Received: from [98.136.164.64] by tm1.bullet.mail.gq1.yahoo.com with NNFMP; 25 Jul 2015 05:07:02 -0000 Received: from [127.0.0.1] by smtp226.mail.gq1.yahoo.com with NNFMP; 25 Jul 2015 05:07:02 -0000 X-Yahoo-Newman-Id: 743206.14981.bm@smtp226.mail.gq1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: E1Nez9YVM1lI27x6I66_QHTjGBBPAuksAOlO_bYwSZru37Q QRF.vYY3cfjOMnUgcLPHq2ZB.bs83TopncdSYA3WpaSX0WNXxpffz4u_ej3z fPaKMTGi.YVlZvefJ1QKFIWPytFwMMpwzyE58xd9gx7EVtYubFf4jEEOKDJ9 63VNcDY0qXwnxd5a2fNI5R7vtlmiIhp7RB_rP8Sa98DoBvWp1ZrhcWrf7b_o 3.vEr9UV.E9zvJyok7KWc717A7oVpb4Bl1W64iibT.cdrBgXeP91H_yT2oNA B_fDoA.eOMS9TpXetHoe6EfJL3PwmT3.m7Qf6F2xhSyoQcEh.XwrtrlGWeyG z3fxRDyygeG_eUBeirFiUnoWKwMtmIcmF2yXbdiNantjWGEEDXMk0tl7kDL_ HhPDn7juC8wVI7Xz8tcYepMjtzV8A.zT9FDT2VAUqO_iASv88TrRtok.nZQg EcyeIYwLtGled5ZHfJShQ521CVZC78tmYqfxixGryM9FWMor5Ftk2chEGSfX OjalsQFDFUVYnkMrEDz3CjyPXeBErqSZbcYlT8dLV X-Yahoo-SMTP: clhABp.swBB7fs.LwIJpv3jkWgo2NU8- Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) 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... From: Scott Long In-Reply-To: Date: Fri, 24 Jul 2015 23:06:59 -0600 Cc: John-Mark Gurney , src-committers , svn-src-all@freebsd.org, svn-src-head@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: <96EA33AB-7325-4DD2-83F4-B4FAF6F47CB5@yahoo.com> References: <201506301700.t5UH0jPq001498@svn.freebsd.org> <20150724012519.GE78154@funkthat.com> To: Mark R V Murray X-Mailer: Apple Mail (2.2098) X-BeenThere: svn-src-all@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: "SVN commit messages for the entire src tree \(except for " user" and " projects" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 Jul 2015 05:12:48 -0000 > On Jul 24, 2015, at 12:59 AM, Mark R V Murray = wrote: >=20 >=20 >> On 24 Jul 2015, at 02:25, John-Mark Gurney 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