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>