Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 16 Apr 2019 16:48:15 -0700
From:      Conrad Meyer <cem@freebsd.org>
To:        John Baldwin <jhb@freebsd.org>
Cc:        src-committers <src-committers@freebsd.org>, svn-src-all <svn-src-all@freebsd.org>,  svn-src-head <svn-src-head@freebsd.org>
Subject:   Re: svn commit: r346250 - in head: share/man/man4 share/man/man9 sys/dev/random sys/kern sys/libkern sys/sys
Message-ID:  <CAG6CVpUskcW9KBPOhevYNQ9fTDd91Rvh2N50Y1xHubSp7JFE4Q@mail.gmail.com>
In-Reply-To: <4d6b8a14-b053-9ed1-14b2-bbc359ac9413@FreeBSD.org>
References:  <201904162251.x3GMp2aF097103@gndrsh.dnsmgr.net> <4d6b8a14-b053-9ed1-14b2-bbc359ac9413@FreeBSD.org>

next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, Apr 16, 2019 at 4:31 PM John Baldwin <jhb@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 :-(.

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

Best,
Conrad



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAG6CVpUskcW9KBPOhevYNQ9fTDd91Rvh2N50Y1xHubSp7JFE4Q>