svn commit: r346250 - in head: share/man/man4 share/man/man9 sys/dev/random sys/kern sys/libkern sys/sys

[Conrad Meyer]

On Tue, Apr 16, 2019 at 6:19 AM Warner Losh <imp at bsdimp.com> wrote:
> On Tue, Apr 16, 2019, 7:04 AM Emmanuel Vadot <manu at 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