From owner-svn-src-all@freebsd.org Wed Apr 17 17:47:11 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 B96CA15740F1 for ; Wed, 17 Apr 2019 17:47:11 +0000 (UTC) (envelope-from ian@freebsd.org) Received: from outbound3d.ore.mailhop.org (outbound3d.ore.mailhop.org [54.186.57.195]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 2DB4B8AF2E for ; Wed, 17 Apr 2019 17:47:11 +0000 (UTC) (envelope-from ian@freebsd.org) ARC-Seal: i=1; a=rsa-sha256; t=1555522261; cv=none; d=outbound.mailhop.org; s=arc-outbound20181012; b=ln/4P8MJhYuEPbUC5DYcz0Eeb6PQQRsnusHkHelzWZhlguwCF/yCyrXAmdGH79DtGkzLPN8JLCChD JxMfqQkGaayAV0do469opdVggWRj0z0x3/uVr5qEzRSt1QNzj3MlRI4SaZUQzGumamEZf+kTIJaKep 31ORIhHGuHJV4xd9TzUoDWZQUgdigkWiDSlWFSc5OfEXtiG4NpWyIb+cDJobzOlN7rVlSpdZgFCI69 nI+JGBE8B+AnxxHzHdIJh6Xl/WhiAKhSmccayYLZpmN0EwQJFw8bO/VH41e5KBsZOxIKDpS5D2MOvd zdwyem4iXwWMHgTxSFLLI8gMBwJ5cNw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=outbound.mailhop.org; s=arc-outbound20181012; h=content-transfer-encoding:mime-version:content-type:references:in-reply-to: date:cc:to:from:subject:message-id:dkim-signature:from; bh=C/lvUl4nM5Ri2eeM6ee2kNdj9jNLip6kilaqv+O7BUw=; b=GO3Xh0N1DWKXy70MFcXenepvnKtpJ7vYFigTzko61Dg60BoCWkoRKX44LUSHrWMN7VfH4V7OvmTi8 G8+bq1UEPvo8GrRKBzjDo9sExzMJ0RoVu3hu8ujnzhORvVh1unz6GkCE4VNMnhmsCC0oFNJgRivtO6 Fs+rhZJyWUWopcmEsIWSOcihBji4SkZkeBVjfCr44NphNV2jA7Vgd0biDmlQN8joj1JZ77dwvaIX0R 79c7ckBMBN53f5AvhdfaxF33sDwUB0KZzCYmpXytQiRGo1u9dgxFLRtm74Fwi/ZxHQ0wOVMe/xzjHm 4jfLicFmjAhHrJZQf7XaDZUyjtUe0sw== ARC-Authentication-Results: i=1; outbound3.ore.mailhop.org; spf=softfail smtp.mailfrom=freebsd.org smtp.remote-ip=67.177.211.60; dmarc=none header.from=freebsd.org; arc=none header.oldest-pass=0; DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=outbound.mailhop.org; s=dkim-high; h=content-transfer-encoding:mime-version:content-type:references:in-reply-to: date:cc:to:from:subject:message-id:from; bh=C/lvUl4nM5Ri2eeM6ee2kNdj9jNLip6kilaqv+O7BUw=; b=vmiSwwjG/OgGe5Pl5o+3pVSy7WBWMaKinqHItQ2Xkxk3+Cl7O21JJ+9BMV9ityUrgl1YtrbE7EWhb MQUjZSdjaP3SQuIe3OvZbg9vIHMKVTmtRIfaqf4aNGY8MVCY/oJE2FD35/c/mo/eefztarLYN2HvMN JiJWRlhRkkZaA3BIU+otppjm64ZbaTdg1vRdMpmFLmFxMP8mICEBn8nPjInMgFQgenWdGSiFlrUKvz aqRUeQvDIMSN+0FeSltoZNwJ8Un09u81YVSNfYOl8EKwjYNAb6Gpe0I9ItxaCeUjTO7TXf68Jlba/8 9VRhtE9d1Lqimg068H9Bbk0RlStisVw== X-MHO-RoutePath: aGlwcGll X-MHO-User: 8febce89-6136-11e9-990e-673a89bc4518 X-Report-Abuse-To: https://support.duocircle.com/support/solutions/articles/5000540958-duocircle-standard-smtp-abuse-information X-Originating-IP: 67.177.211.60 X-Mail-Handler: DuoCircle Outbound SMTP Received: from ilsoft.org (unknown [67.177.211.60]) by outbound3.ore.mailhop.org (Halon) with ESMTPSA id 8febce89-6136-11e9-990e-673a89bc4518; Wed, 17 Apr 2019 17:30:59 +0000 (UTC) Received: from rev (rev [172.22.42.240]) by ilsoft.org (8.15.2/8.15.2) with ESMTP id x3HHUvCE047206; Wed, 17 Apr 2019 11:30:58 -0600 (MDT) (envelope-from ian@freebsd.org) Message-ID: <78a8423ede681a7ab6572c508ec800d9cffb562b.camel@freebsd.org> Subject: Re: svn commit: r346250 - in head: share/man/man4 share/man/man9 sys/dev/random sys/kern sys/libkern sys/sys From: Ian Lepore To: Warner Losh , John Baldwin Cc: "Conrad E. Meyer" , src-committers , svn-src-all , svn-src-head Date: Wed, 17 Apr 2019 11:30:57 -0600 In-Reply-To: References: <201904162251.x3GMp2aF097103@gndrsh.dnsmgr.net> <4d6b8a14-b053-9ed1-14b2-bbc359ac9413@FreeBSD.org> <48b25255-3d66-69fc-658b-6176ebaf4640@FreeBSD.org> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.28.5 FreeBSD GNOME Team Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 2DB4B8AF2E 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_LONG(-1.00)[-1.000,0]; REPLY(-4.00)[]; NEURAL_HAM_SHORT(-0.99)[-0.991,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:47:12 -0000 On Wed, 2019-04-17 at 11:16 -0600, Warner Losh wrote: > 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 I'll add a big +1 to all of that, it all directly applies to our embedded products at $work as well, and would give us the control we need to handle things in an application-specific way. -- Ian