On Tue, Apr 16, 2019 at 6:19 AM Warner Losh <i...@bsdimp.com> wrote: > On Tue, Apr 16, 2019, 7:04 AM Emmanuel Vadot <m...@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 _______________________________________________ svn-src-head@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"