Date: Wed, 17 Apr 2019 11:30:57 -0600 From: Ian Lepore <ian@freebsd.org> To: Warner Losh <imp@bsdimp.com>, John Baldwin <jhb@freebsd.org> Cc: "Conrad E. Meyer" <cem@freebsd.org>, 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: <78a8423ede681a7ab6572c508ec800d9cffb562b.camel@freebsd.org> In-Reply-To: <CANCZdfrUYbE89nHkKWkNiktmSGyE=jAX_jQk5ZxY-%2B6GZZNoJg@mail.gmail.com> References: <201904162251.x3GMp2aF097103@gndrsh.dnsmgr.net> <4d6b8a14-b053-9ed1-14b2-bbc359ac9413@FreeBSD.org> <CAG6CVpUskcW9KBPOhevYNQ9fTDd91Rvh2N50Y1xHubSp7JFE4Q@mail.gmail.com> <48b25255-3d66-69fc-658b-6176ebaf4640@FreeBSD.org> <CANCZdfrUYbE89nHkKWkNiktmSGyE=jAX_jQk5ZxY-%2B6GZZNoJg@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, 2019-04-17 at 11:16 -0600, Warner Losh wrote: > On Wed, Apr 17, 2019 at 10:06 AM John Baldwin <jhb@freebsd.org> wrote: > > > On 4/16/19 4:48 PM, Conrad Meyer wrote: > > > 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 > > > > :-(. > > > > 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?78a8423ede681a7ab6572c508ec800d9cffb562b.camel>