From owner-svn-src-head@freebsd.org Tue Apr 16 16:33:07 2019 Return-Path: Delivered-To: svn-src-head@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id C700B1577466 for ; Tue, 16 Apr 2019 16:33:07 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-qk1-x72b.google.com (mail-qk1-x72b.google.com [IPv6:2607:f8b0:4864:20::72b]) (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 5D7F16D4A3 for ; Tue, 16 Apr 2019 16:33:07 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-qk1-x72b.google.com with SMTP id k189so12549918qkc.0 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=lGW2OMQA9ymF9sBdeQ1uyBTD7NtEbkq2krzjvCgdLqN/iA++FgXF6RJfJXf6tQ70ci FROjMWR6YHDotcxlGhhVb3xe/wdbxq4ZX4nIuabM21xukQyjiBwcs2GubNE9iXZm9r+j JWyozP+XpYZMrjd1/1TdguqTKPaz7pA8JgfvhbMvyiek2wC7o4n3aTlBVqhZLDvu/CGf 7Dpl3u01hrcgKg4CSJaMRj3eR9cJOF0HF2o1pa+qLZTsJwXQ03yP2GAjIHQztWxI7uVo 1724Uh6OYt9DM6lIxo4kemTnISmbXLQBLK+SMmkTXmhtK1QTVTqYkAtzXkwSdygyh2nk w/7g== X-Gm-Message-State: APjAAAWKtXhRfb/AtFzROkMAKirYagzgTXv5PtVLUnb2exvowRtWW5ii bU6o5cagk0a7tWpM6OAYqc/AhkLCJoaF4kU1uBW3DbbR 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 Date: Tue, 16 Apr 2019 10:32:55 -0600 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 X-Rspamd-Queue-Id: 5D7F16D4A3 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.985,0]; REPLY(-4.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000,0] Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.29 X-BeenThere: svn-src-head@freebsd.org X-Mailman-Version: 2.1.29 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: Tue, 16 Apr 2019 16:33:08 -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