From owner-svn-src-all@freebsd.org Wed Apr 17 17:44:26 2019 Return-Path: Delivered-To: svn-src-all@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 DC35A1573FA7; Wed, 17 Apr 2019 17:44:25 +0000 (UTC) (envelope-from cse.cem@gmail.com) Received: from mail-it1-f194.google.com (mail-it1-f194.google.com [209.85.166.194]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 76BE88AD41; Wed, 17 Apr 2019 17:44:25 +0000 (UTC) (envelope-from cse.cem@gmail.com) Received: by mail-it1-f194.google.com with SMTP id f22so5767409ita.3; Wed, 17 Apr 2019 10:44:25 -0700 (PDT) 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:reply-to :from:date:message-id:subject:to:cc:content-transfer-encoding; bh=N0LHj1zKA1tsqFuEKQ471jQTsnOmHDs7uuv69zXbhXM=; b=jv1nnDHkN1blCY+zm57NPd4Tm/BgEoFVYiOBlCAs5ARxAlce6oaBMaROYFqXbl2axB b1BONVWWE/D5XAhHjzcCDxWM2AlD5HKUtGEf0mpIF/nLvBQYiteRqs6HuGEchrYhVfur gXIqkkpQ03kYe5lCv9lltizPuRNyLgyB7n/UKb+hn25AXgtzg8BtgkpL9j4HznJt0FCV H8BgGkWfvK2bGacXcqDgFAbag9iUMQIjBSArcWKlZWU4THCHwlQkWEWrZSgurNZ2Dtik /8Ln+lvmrt3wtid/k5iOxHyVfcOHWVPWeOsJ06pwkrfcXEeMHkvKwAuGTlBtRsn5l2KG bHjQ== X-Gm-Message-State: APjAAAVvo9XXiUAIt/M9gAI2aeuoyQgR98bFStL6gXYIoniPDbiv/zah 6FhuEfu3O9O6YybmKIUfVebI0pGx X-Google-Smtp-Source: APXvYqyJ2Jt3snTOqh1L1f0YCe6JNn+wAhh41f65bZ/Ic0PLHLEzcKn8BxcwLDqdFvyEMaRF7gH2DQ== X-Received: by 2002:a24:68c2:: with SMTP id v185mr720348itb.94.1555522571090; Wed, 17 Apr 2019 10:36:11 -0700 (PDT) Received: from mail-io1-f41.google.com (mail-io1-f41.google.com. [209.85.166.41]) by smtp.gmail.com with ESMTPSA id m132sm21391683ioa.53.2019.04.17.10.36.10 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 17 Apr 2019 10:36:10 -0700 (PDT) Received: by mail-io1-f41.google.com with SMTP id x3so21239776iol.10; Wed, 17 Apr 2019 10:36:10 -0700 (PDT) X-Received: by 2002:a6b:691a:: with SMTP id e26mr31328433ioc.124.1555522570364; Wed, 17 Apr 2019 10:36:10 -0700 (PDT) MIME-Version: 1.0 References: <201904162251.x3GMp2aF097103@gndrsh.dnsmgr.net> <4d6b8a14-b053-9ed1-14b2-bbc359ac9413@FreeBSD.org> <48b25255-3d66-69fc-658b-6176ebaf4640@FreeBSD.org> In-Reply-To: Reply-To: cem@freebsd.org From: Conrad Meyer Date: Wed, 17 Apr 2019 10:35:59 -0700 X-Gmail-Original-Message-ID: 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: Warner Losh Cc: src-committers , svn-src-all , svn-src-head Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: 76BE88AD41 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.981,0]; REPLY(-4.00)[]; TAGGED_FROM(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000,0] X-BeenThere: svn-src-all@freebsd.org X-Mailman-Version: 2.1.29 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: Wed, 17 Apr 2019 17:44:26 -0000 Hi Warner, On Wed, Apr 17, 2019 at 10:16 AM Warner Losh wrote: > I'm going to put a very fine point on this: any hard-requirement of entro= py sources is a non-starter. If you require that, your commit will be backe= d out and/or hacked around by the addition of a nob in the future. It will = happen. Don't pretend you can say 'but things weren't random enough' will c= arry the day. It will not. > > That's why I specifically requested a MD routine to be called when there'= s no source of entropy: that will let special needs folks do the right thin= g. It's also why I asked for a way to say "don't ever block waiting for ent= ropy, soldier on the best you can, but set some variable that can be expose= d to userland so that early in /etc/rc automation can be written to decide = what to do when that condition exists: generate entropy and reboot, report = it to some central control, nothing" since that will give the tools for dif= ferent reactions. > > For our application it is *NEVER* OK to block the boot because there's no= t enough randomness. We'd rather solider on with crappy randomness and want= the boot to proceed not matter what. We want the information that we had t= o make compromises along the way to make it happen so we can decide the rig= ht course of action for our appliances. I think John's proposed big knob to disable hard-requirement of entropy, and a warning on dmesg, pretty much covers your applications' needs. Do you agree? The random framework has already got ways to register random sources; special needs MD folks can always register their own fako fast random source. I.e., the randomdev entropy intake framework is already general with room for MD-specific drivers (of which several exist today). Take care, Conrad