From owner-svn-src-all@freebsd.org Tue Sep 3 14:07:49 2019 Return-Path: Delivered-To: svn-src-all@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 E542DDD22A; Tue, 3 Sep 2019 14:06:57 +0000 (UTC) (envelope-from yuripv@freebsd.org) Received: from freefall.freebsd.org (freefall.freebsd.org [96.47.72.132]) (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 46N8012hsmz4Q56; Tue, 3 Sep 2019 14:06:57 +0000 (UTC) (envelope-from yuripv@freebsd.org) Received: by freefall.freebsd.org (Postfix, from userid 1452) id 237821AE2B; Tue, 3 Sep 2019 14:06:23 +0000 (UTC) X-Original-To: yuripv@localmail.freebsd.org Delivered-To: yuripv@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 16C2D1F4B5; Tue, 16 Apr 2019 16:33:11 +0000 (UTC) (envelope-from owner-src-committers@freebsd.org) Received: from freefall.freebsd.org (freefall.freebsd.org [96.47.72.132]) (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 3358C6D4A8; Tue, 16 Apr 2019 16:33:10 +0000 (UTC) (envelope-from owner-src-committers@freebsd.org) Received: by freefall.freebsd.org (Postfix, from userid 538) id 17EE81F492; Tue, 16 Apr 2019 16:33:10 +0000 (UTC) Delivered-To: src-committers@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 86D181F48E for ; Tue, 16 Apr 2019 16:33:07 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-qk1-x733.google.com (mail-qk1-x733.google.com [IPv6:2607:f8b0:4864:20::733]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 2FA066D4A2 for ; Tue, 16 Apr 2019 16:33:07 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-qk1-x733.google.com with SMTP id a71so12545493qkg.2 for ; Tue, 16 Apr 2019 09:33:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=hSv5QYTgJ8vuuz6EDzVV3PinrDfGNtJFdph2p8Uo0eM=; b=ObmqjP/LBlfr2Atp7Yq7v+xk7g291tedU97zxr6BQYLGUVmUP3KSKC3BmuTZpuAEqH tFXOc3bNNLIxIevDtZF2F1uney+hbQDQdfkXe+Rw4LuAV2x9Y0QTmp00x7QlhUOJfqXe 90mBWSWONbygxh4fVhG5nDEHIJY0i2QRrwZD+v2dzbrTUT7lUwETRqpLJy1zoRuxmT77 kHwIJtqYiJqou1v6xj7LK8VGZnylME1MxeS5VnAM2rnvJbyqttxSE6/4nstSmTlOtLOQ 50TNm2JnB679eSXeGmeOjrWEszWI7BRYyZzM9q4AjVzsBUiHp0rCpCs9F+/3xLRLxTMq M4mg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=hSv5QYTgJ8vuuz6EDzVV3PinrDfGNtJFdph2p8Uo0eM=; b=R+FLUeEnRGULAetkSZq/QuVsdbfIFu5BOWsoCFyrzgJde1eoxJJzaRvDHWqaaY07Q1 oNwQOf71kaUK4uHQvMWQjxa6XJ5Cj9T4xnDhNqCZyHBKxU+ysDg1rljxT+tv9pcBqQuh z6dvGfMRdCaqHISetIpZpIqI1vFfk3CRreJHqroSi1AdNsZ1ZJJmQ9MoGPtdX6V7lxZN VRjXQlVo9q1080OAkZIt7t5Fdi/5uAwCsgZqxy4BWgVE+lfw8pjOVxZuDI5Bka6zWpYU KMZG7AiI+EIFwqaCaglFWVZQCWurYOCLTA/O/yQ5naZTu5mGtj11BhAEu72MeN5MAktt Ya7w== X-Gm-Message-State: APjAAAVODEyVXKjnwLL7GNFWqSEYClpRWfMve6TSzP3TKPOdFkJLh3Cc /khIoAT8ZjF+Rv4vbDcDPzWBELodxIoZrQ37W3jVUw== X-Google-Smtp-Source: APXvYqx1cVrE8upgVM7yL56pKGbuhDRtzRG5jMDyRrbUOVp8aeG1FsLQg7jGB9WG1hrSDgUrtJu/Gx1cvBOMqJpIJVY= X-Received: by 2002:a37:9e0d:: with SMTP id h13mr63940311qke.135.1555432386521; Tue, 16 Apr 2019 09:33:06 -0700 (PDT) MIME-Version: 1.0 References: <201904151840.x3FIeaEQ009242@repo.freebsd.org> <20190416150352.c604a280368ccb2992a861e8@bidouilliste.com> <310a420ee0b9e12249979d89dc4fa0d4cac5a8dc.camel@freebsd.org> In-Reply-To: From: Warner Losh Message-ID: Subject: Re: svn commit: r346250 - in head: share/man/man4 share/man/man9 sys/dev/random sys/kern sys/libkern sys/sys To: "Conrad E. Meyer" Cc: src-committers , svn-src-all , svn-src-head Precedence: bulk X-Loop: FreeBSD.org Sender: owner-src-committers@freebsd.org X-Rspamd-Queue-Id: 3358C6D4A8 X-Spamd-Bar: ------ Authentication-Results: mx1.freebsd.org X-Spamd-Result: default: False [-6.99 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; NEURAL_HAM_SHORT(-0.99)[-0.987,0]; REPLY(-4.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000,0] Status: O Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.29 X-BeenThere: svn-src-all@freebsd.org X-Mailman-Version: 2.1.29 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: , Date: Tue, 03 Sep 2019 14:07:49 -0000 X-Original-Date: Tue, 16 Apr 2019 10:32:55 -0600 X-List-Received-Date: Tue, 03 Sep 2019 14:07:49 -0000 On Tue, Apr 16, 2019 at 9:51 AM Conrad Meyer wrote: > Hi Warner, > > On Tue, Apr 16, 2019 at 8:47 AM Warner Losh wrote: > > On Tue, Apr 16, 2019 at 9:16 AM Ian Lepore wrote: > >> Isn't a file full of data which is distributed in identical form to > >> everyone the exact opposite of entropy? > > Ian has the right idea. > > > It's just to bootstrap entropy for installs. The CI stuff doesn't matter > if that's the same since the CI images aren't exposed to the internet in > any way that would make it matter. The normal install would have the same > seeds of entropy, but diverge from there fairly quickly. The stuff that's > used early in the install is the don't care sort of things that won't > matter in the installer (which then creates it's own entropy that's > different for every install). > > I agree that it would be safe, although potentially misleading and > potentially dangerous, to create a fake entropy file for the installer > images. We need to be careful *not* to embed such files in .img files > which are installed by 'dd' directly to a disk or flash or VM, for > example. It would be catastrophic to distribute the same entropy file > to all FreeBSD AWS images. > In that case, we're better off having a MD routine that gets called if there's no loader-provided entropy pool. It would be responsible for generating it in a MD defined way. It would handle it or call panic() based on the requirements of the environment. This would answer the issue with embedded systems that do not have any writable store (and requiring an NV store is not even an option to require, so don't go there). It would let hardware with RNG generate something. It would let hardware without get it from wherever which may be highly specific to different scenarios or make the conscious decision not to get it at all vs panic, etc. What we can't do is just hang if the loader can't provide an entropy pool. Warner