From owner-svn-src-head@freebsd.org Fri Jul 24 06:59:46 2015 Return-Path: Delivered-To: svn-src-head@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 DB4CA9A7050; Fri, 24 Jul 2015 06:59:46 +0000 (UTC) (envelope-from markm@FreeBSD.org) Received: from gromit.grondar.org (grandfather.grondar.org [IPv6:2a01:348:0:15:5d59:5c20:0:2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 96E7E1F9D; Fri, 24 Jul 2015 06:59:46 +0000 (UTC) (envelope-from markm@FreeBSD.org) Received: from graveyard.grondar.org ([88.96.155.33] helo=gronkulator.grondar.org) by gromit.grondar.org with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.85 (FreeBSD)) (envelope-from ) id 1ZIWxJ-000MoX-84; Fri, 24 Jul 2015 07:59:41 +0100 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... Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2102\)) Content-Type: text/plain; charset=utf-8 From: Mark R V Murray In-Reply-To: <20150724012519.GE78154@funkthat.com> Date: Fri, 24 Jul 2015 07:59:35 +0100 Cc: src-committers , svn-src-all@freebsd.org, svn-src-head@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <201506301700.t5UH0jPq001498@svn.freebsd.org> <20150724012519.GE78154@funkthat.com> To: John-Mark Gurney X-Mailer: Apple Mail (2.2102) X-SA-Score: -1.0 X-BeenThere: svn-src-head@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: SVN commit messages for the src tree for head/-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jul 2015 06:59:47 -0000 > 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. 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. > 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. 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. > 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. 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. > Heck, piping in mic data to /dev/random is a good way to seed the > rng on many machines. 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. M --=20 Mark R V Murray