svn commit: r346250 - in head: share/man/man4 share/man/man9 sys/dev/random sys/kern sys/libkern sys/sys

[Ian Lepore]

On Wed, 2019-04-17 at 11:16 -0600, Warner Losh wrote:
> On Wed, Apr 17, 2019 at 10:06 AM John Baldwin <jhb at freebsd.org> wrote:
> 
> > On 4/16/19 4:48 PM, Conrad Meyer wrote:
> > > On Tue, Apr 16, 2019 at 4:31 PM John Baldwin <jhb at freebsd.org> 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