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>
index | next in thread | previous in thread | raw e-mail
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, Conradhome | help
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAG6CVpUskcW9KBPOhevYNQ9fTDd91Rvh2N50Y1xHubSp7JFE4Q>