On Wed, 2019-04-17 at 11:16 -0600, Warner Losh wrote: > On Wed, Apr 17, 2019 at 10:06 AM John Baldwin <j...@freebsd.org> wrote: > > > On 4/16/19 4:48 PM, Conrad Meyer wrote: > > > On Tue, Apr 16, 2019 at 4:31 PM John Baldwin <j...@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 _______________________________________________ svn-src-head@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
