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

[John Baldwin]

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.

>> 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.

-- 
John Baldwin