Date: Tue, 16 Apr 2019 08:17:24 -0700 From: Conrad Meyer <cem@freebsd.org> To: Warner Losh <imp@bsdimp.com> 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: <CAG6CVpVbjYQ=_XU8BAPdd1GP1iXr-iX2c9jig24F1pZLUrz2dA@mail.gmail.com> In-Reply-To: <CANCZdfqwfdPnr3HBAw6=YdPW_0yLsS4OpJMhiqFxWSM6BVJ-Zw@mail.gmail.com> References: <201904151840.x3FIeaEQ009242@repo.freebsd.org> <CAPyFy2D9NQQKwVx5MhCfasQ82x7C9s6mj5kXuDE1oogrQeoJ5A@mail.gmail.com> <CAHSQbTAfwYcLenBxg4ZB13P03S%2BTYEM1-xy3BYsSWJ49hBWLZA@mail.gmail.com> <CAG6CVpXwOhSpmCT1SShvEOZAdjbQSk5xSzk%2BLk8c5fMpnhSKQw@mail.gmail.com> <CAG6CVpUqy75_iEU-OwC21LOQFrXTO7rMz3B4iHi7GBTfsqK_5w@mail.gmail.com> <20190416150352.c604a280368ccb2992a861e8@bidouilliste.com> <CANCZdfqwfdPnr3HBAw6=YdPW_0yLsS4OpJMhiqFxWSM6BVJ-Zw@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, Apr 16, 2019 at 6:19 AM Warner Losh <imp@bsdimp.com> wrote: > On Tue, Apr 16, 2019, 7:04 AM Emmanuel Vadot <manu@bidouilliste.com> wrote: >> It's not only CI, all release images (memstick, iso) don't have >> a /boot/entropy. >> Also all arm/arm64 image don't have this file too. >> If /boot/entropy is needed and isn't present loader(8) should gather >> some entropy and pass this to the kernel for the first boot. > > Maybe we need to bootstrap the entropy file as part of buildworld. I'm not sure if the loader can find enough... Well, one thing we should explicitly *not do* is distribute the same "entropy" to everyone in released images. So there is some difficulty here. Buildworld does not know if the target of the build is a one-off or a release image. Something like makerelease still seems inappropriately dangerous. The idea of loader-provided entropy is not that it generates the entropy itself, but that it can access the /boot/ filesystem to load entropy and pass it to the kernel as a fake module. I think we have identified that at least stack_chk_init was silently broken on a number of systems, using non-random stack guards. Now it's loudly broken. Ed has proposed a happy medium where we can check, in stack_chk_init, if the random device is seeded (via new KPI) and give users a big stick tunable to proceed without entropy or not. For now, I think we would default that to "proceed" just to unbreak CI and any other sharp corners. But the goal would be to default that to "panic" eventually. I don't know enough about stack_chk_init to determine how late it can be seeded. It seems to have come in in r180012 as a component of -fstack-protector. I will do a little investigating. Suggestions on appropriate reviewers welcome (I think ru@ is no longer with the project). Best regards, Conrad
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAG6CVpVbjYQ=_XU8BAPdd1GP1iXr-iX2c9jig24F1pZLUrz2dA>