From owner-svn-src-all@freebsd.org Tue Sep 3 14:07:54 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 4B74ADD31D; Tue, 3 Sep 2019 14:07:01 +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 46N8046BJTz4Q8h; Tue, 3 Sep 2019 14:07:00 +0000 (UTC) (envelope-from yuripv@freebsd.org) Received: by freefall.freebsd.org (Postfix, from userid 1452) id 110E41AF6B; Tue, 3 Sep 2019 14:06:26 +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 CBDA713CFA; Wed, 17 Apr 2019 17:16:58 +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 313E5895A0; Wed, 17 Apr 2019 17:16:58 +0000 (UTC) (envelope-from owner-src-committers@freebsd.org) Received: by freefall.freebsd.org (Postfix, from userid 538) id 0DFDE13CC8; Wed, 17 Apr 2019 17:16:58 +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 08ECC13CC2 for ; Wed, 17 Apr 2019 17:16:55 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-qk1-x741.google.com (mail-qk1-x741.google.com [IPv6:2607:f8b0:4864:20::741]) (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 A120F89599 for ; Wed, 17 Apr 2019 17:16:54 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-qk1-x741.google.com with SMTP id w20so14813312qka.7 for ; Wed, 17 Apr 2019 10:16:54 -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=AzK1QqsIhvko8X6L/mAALXziKCYba6+xw/6grpAL7r0=; b=B2tapYqCXif3reFRUe1MU3/EtBoW5VNOQXrSVyu8OFto/x860UCu+LaLwIhI/jcYsX ULFgGlZfdEcYhlhgHR0L3cho/phGW6RsFzd9mU2CuOpf8wiCPX5kXie08HRCDlCO+OTi DGkqqVLMsr0c2UaroHDv1XZWVsI1lJXYHw5ZPNH+QdZo7kdxtWiaPN+b6qpjxPibxW85 Y1Sm1Vhw66hUUjAKKrgU9OKiGwDF+TcNhPDPtZOm9EVJyef7RV41kSt3EdqPKAUESQVw io/FgjlsZM1XyuRXnjj4uI6dcmJCLez9fdgbpjLlDLERxhtR12qEGPZ/Ol8ZpTXyLWFD bVXg== 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=AzK1QqsIhvko8X6L/mAALXziKCYba6+xw/6grpAL7r0=; b=J0Vv/z4rcLTlmWoygandAVCBEZTMxWDRpsLkyLtEt0J3XcZq4s1ZiB2zV+mJTo67pF ubYlfeXi3zPWhwklaYKLLjOwbLXJj9IEJ2q04VYRUy1WQX92eL6tqoFy7aSXcc91ahxg 7Zpz5z5Ygl+v6tuf61OapP+mwItMzHSc2kxLeSroQc3zbhzL0fr4seHMwCOQteaprojy psQqovFB9+8N5XeqUtieQvdCrgq0E0yxkqXRFzxZZuW7gOjGgF546Y2EAro8RdKaWa0e C7lGEdRVJiHz8h5IN+A5ZCje8hiJ3s2rjPd1v1kirjzs2yO6aPd12Gng6kmJNwLS+9xO hCGw== X-Gm-Message-State: APjAAAX+eaj+mgwR2gvNVIrA2WlzULpJxJyLhDezZX1nmttKaCC3dNj2 29cd2HSLmgmNdnCe5+WTVsZ03nEkB0JX3k60jrdvFpGh X-Google-Smtp-Source: APXvYqz4Vm4ZYbGY/j+WuHmwCDXc0mmegMtO26R8LwI73sUy8acjd/2RSetSHbl91Ontn02o/XZPt/9BuVHXUa1QQso= X-Received: by 2002:a37:a02:: with SMTP id 2mr25002843qkk.258.1555521413890; Wed, 17 Apr 2019 10:16:53 -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: <48b25255-3d66-69fc-658b-6176ebaf4640@FreeBSD.org> 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: John Baldwin Cc: "Conrad E. Meyer" , src-committers , svn-src-all , svn-src-head Precedence: bulk X-Loop: FreeBSD.org Sender: owner-src-committers@freebsd.org X-Rspamd-Queue-Id: 313E5895A0 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.983,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:54 -0000 X-Original-Date: Wed, 17 Apr 2019 11:16:42 -0600 X-List-Received-Date: Tue, 03 Sep 2019 14:07:54 -0000 On Wed, Apr 17, 2019 at 10:06 AM John Baldwin wrote: > On 4/16/19 4:48 PM, Conrad Meyer wrote: > > On Tue, Apr 16, 2019 at 4:31 PM John Baldwin wrote: > >> bhyveload is effectively the loader in this case. It runs the normal > loader > >> scripts and logic and so would load the guests's /boot/entropy and pass > it > >> to the guest kernel as metadata just like the regular loader. > > > > Right, except it doesn't seem to do things like nuke /boot/nextboot.conf > :-(. > > It just needs a disk write method I think for that to work, but I'm not > sure > that's currently in the userboot interface. > It isn't. Write support was added to the boot loader after bhyveload was forked. It hasn't been updated. > >> In addition, bhyve also supports virtio-rng which is another way to > provide > >> entropy to guest OS's. That's why in my reply I focused on qemu for > mips > >> (or riscv) as for x86 hypervisors there are existing, > somewhat-standarized > >> solutions for the hypervisor to provide entropy to the guest. > > > > Perhaps cryptographically random stack-protector cookies are simply > > inappropriate for MIPS or RISCV. Do we have any other examples of > > kernel random consumers blocking after that immediate hiccup is > > overcome? > > There may be MIPS and RISCV designs that do have suitable entropy available > (especially I would expect future RISCV designs to have them), so I think > blacklisting stack protector wholesale on those architectures is overboard. > I think some sort of off-by-default knob (even a compile option) is fine > for > people who need fast and loose vs safe as you already agreed to earlier. > > Also, for development testing we still want coverage of using stack cookies > on MIPS and RISCV even if the simulator environment gives not-very-strong > cookie values. I'm going to put a very fine point on this: any hard-requirement of entropy sources is a non-starter. If you require that, your commit will be backed 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 carry 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 thing. It's also why I asked for a way to say "don't ever block waiting for entropy, soldier on the best you can, but set some variable that can be exposed 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 different reactions. For our application it is *NEVER* OK to block the boot because there's not 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 to make compromises along the way to make it happen so we can decide the right course of action for our appliances. Warner