From owner-svn-src-head@freebsd.org Tue Sep 3 14:07:08 2019 Return-Path: Delivered-To: svn-src-head@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 888B5DD284; Tue, 3 Sep 2019 14:06:59 +0000 (UTC) (envelope-from yuripv@freebsd.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2610:1c1:1:6074::16:84]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "freefall.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 46N8026WnXz4Q6M; Tue, 3 Sep 2019 14:06:58 +0000 (UTC) (envelope-from yuripv@freebsd.org) Received: by freefall.freebsd.org (Postfix, from userid 1452) id 09E261AE8B; Tue, 3 Sep 2019 14:06:24 +0000 (UTC) X-Original-To: yuripv@localmail.freebsd.org Delivered-To: yuripv@localmail.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) (Client CN "mx1.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by freefall.freebsd.org (Postfix) with ESMTPS id C02B65FC5; Tue, 16 Apr 2019 22:51:08 +0000 (UTC) (envelope-from owner-src-committers@freebsd.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2610:1c1:1:6074::16:84]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "freefall.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 2D66983B9F; Tue, 16 Apr 2019 22:51:08 +0000 (UTC) (envelope-from owner-src-committers@freebsd.org) Received: by freefall.freebsd.org (Postfix, from userid 538) id 1B5AE5FC3; Tue, 16 Apr 2019 22:51:08 +0000 (UTC) Delivered-To: src-committers@localmail.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [96.47.72.80]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) (Client CN "mx1.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by freefall.freebsd.org (Postfix) with ESMTPS id 6E0C15FBF; Tue, 16 Apr 2019 22:51:04 +0000 (UTC) (envelope-from freebsd@gndrsh.dnsmgr.net) Received: from gndrsh.dnsmgr.net (br1.CN84in.dnsmgr.net [69.59.192.140]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id E098883B84; Tue, 16 Apr 2019 22:51:03 +0000 (UTC) (envelope-from freebsd@gndrsh.dnsmgr.net) Received: from gndrsh.dnsmgr.net (localhost [127.0.0.1]) by gndrsh.dnsmgr.net (8.13.3/8.13.3) with ESMTP id x3GMp2n9097104; Tue, 16 Apr 2019 15:51:02 -0700 (PDT) (envelope-from freebsd@gndrsh.dnsmgr.net) Received: (from freebsd@localhost) by gndrsh.dnsmgr.net (8.13.3/8.13.3/Submit) id x3GMp2aF097103; Tue, 16 Apr 2019 15:51:02 -0700 (PDT) (envelope-from freebsd) From: "Rodney W. Grimes" Message-Id: <201904162251.x3GMp2aF097103@gndrsh.dnsmgr.net> Subject: Re: svn commit: r346250 - in head: share/man/man4 share/man/man9 sys/dev/random sys/kern sys/libkern sys/sys In-Reply-To: <457a2c63-f062-8fc6-15d4-6f5b93981930@FreeBSD.org> To: John Baldwin CC: Conrad Meyer , src-committers@freebsd.org, svn-src-all@freebsd.org, svn-src-head@freebsd.org Reply-To: rgrimes@freebsd.org X-Mailer: ELM [version 2.4ME+ PL121h (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII Precedence: bulk X-Loop: FreeBSD.org Sender: owner-src-committers@freebsd.org X-Rspamd-Queue-Id: 2D66983B9F X-Spamd-Bar: ------ Authentication-Results: mx1.freebsd.org X-Spamd-Result: default: False [-6.98 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; NEURAL_HAM_SHORT(-0.98)[-0.980,0]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; REPLY(-4.00)[] Status: O X-BeenThere: svn-src-head@freebsd.org X-Mailman-Version: 2.1.29 List-Id: SVN commit messages for the src tree for head/-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Date: Tue, 03 Sep 2019 14:07:08 -0000 X-Original-Date: Tue, 16 Apr 2019 15:51:02 -0700 (PDT) X-List-Received-Date: Tue, 03 Sep 2019 14:07:08 -0000 > On 4/15/19 11:40 AM, Conrad Meyer wrote: > > Author: cem > > Date: Mon Apr 15 18:40:36 2019 > > New Revision: 346250 > > URL: https://svnweb.freebsd.org/changeset/base/346250 > > > > Log: > > random(4): Block read_random(9) on initial seeding > > > > read_random() is/was used, mostly without error checking, in a lot of > > very sensitive places in the kernel -- including seeding the widely used > > arc4random(9). > > > > Most uses, especially arc4random(9), should block until the device is seeded > > rather than proceeding with a bogus or empty seed. I did not spy any > > obvious kernel consumers where blocking would be inappropriate (in the > > sense that lack of entropy would be ok -- I did not investigate locking > > angle thoroughly). In many instances, arc4random_buf(9) or that family > > of APIs would be more appropriate anyway; that work was done in r345865. > > There are definitely places arc4random is used where sleeping is not allowed. > ipsec generating nonces for AES-CBC is one example I can think of off the > top of my head. I think it might be useful to add an explicit WITNESS_WARN > in arc4random to catch these cases so they can be found and reasoned about. > > > This change primarily impacts the behavior of /dev/random on embedded > > systems with read-only media that do not configure "nodevice random". We > > toggle the default from 'charge on blindly with no entropy' to 'block > > indefinitely.' This default is safer, but may cause frustration. Embedded > > system designers using FreeBSD have several options. The most obvious is to > > plan to have a small writable NVRAM or NAND to persist entropy, like larger > > systems. Early entropy can be fed from any loader, or by writing directly > > to /dev/random during boot. Some embedded SoCs now provide a fast hardware > > entropy source; this would also work for quickly seeding Fortuna. A 3rd > > option would be creating an embedded-specific, more simplistic random > > module, like that designed by DJB in [1] (this design still requires a small > > rewritable media for forward secrecy). Finally, the least preferred option > > might be "nodevice random", although I plan to remove this in a subsequent > > revision. > > Note that I actually often run into unseeded systems when doing development > using qemu for non-x86 architectures. For example, when booting mips from > qemu, there is no loader, the kernel just starts, and since the endian is > opposite, I frequently regenerate the filesystem using makefs. Isnt this also the case for bhyveload? We do not go through the loader there when we are starting a FreeBSD guest, correct? > John Baldwin -- Rod Grimes rgrimes@freebsd.org