[Bug 262192] Crashes at boot with kern.random.initial_seeding.bypass_before_seeding=0 in randomdev_wait_until_seeded()

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=262192

--- Comment #5 from Olivier Certner <olivier.freebsd@free.fr> ---
(In reply to Conrad Meyer from comment #4)

Hi Conrad,

> First order fix is to figure out why you don't have /boot/entropy
> (or whatever) and fix that.  (Most VMs don't have this problem.)

Thanks for pointing this out. The image is entirely custom and indeed I didn't
generate some entropy file for boot.

I could create "/boot/entropy" to avoid the panic, but I fear that this
"solution" could actually threaten security in the following use case: Having a
read-only image (VM, CD-ROM or USB) that is always used to boot a machine.

In this case, the same "/boot/entropy" will be used over and over, leading to
the same guard at each boot (similarly to the static guard used in the code
before e199792d23341b0a; the only slight advantage is that the static guard
would not be known in advance by simple source code inspection). Worse, it
consumes only part of the entropy, so later subsystems using arc4rand() will
also consume the same entropy boot after boot, until no more entropy is
available and the generator has to be reseeded.

If my reasoning is correct, this means that providing a constant
"/boot/entropy" will effectively, for the first routines needing random
numbers, bypass the security offered by
"kern.random.initial_seeding.bypass_before_seeding set to 0". Don't know the
practical extent of the problem (who does request random bytes at boot, and for
what), but this is a priori worrying.

>Second order workaround is to revert e199792d23341b0a887bf54c262147b213edd556
> and set security.stack_protect.permit_nonrandom_cookies=1.
> This is practically similar to not compiling in stackcookies at all.

At least, this solution avoids these concerns, at the price of a static guard.
I agree that this means no stack cookies at all, but only in the perspective of
a deliberate attack (the mechanism stays useful to uncover stack overflow bugs)
and provided I don't change the hardcoded value myself (then the canary would
still have to be discovered once, as if the same "/boot/loader.conf" is used
over and over; this is weaker than the current vanilla randomization).

> Third option is to set kern.random.initial_seeding.bypass_before_seeding=1.

Yes, but that's precisely what I've been trying to avoid from the start. I want
the random source to always be seeded; if it is not then the system has to wait
until there is enough entropy.

> Could this be better?  Sure. (snip)

Interesting possibilities to look at. Thanks. I may look at that (not before
several weeks, unfortunately) if Kyle doesn't in the meantime.

Don't know the inner details of SSP, but is the same guard used for all
processes/threads? I assume that __stack_chk_guard is salted with specific
process/thread info, or some other random source. So it might possible to live
with a static guard initially (influencing only some kernel processes) and then
change it while entropy is available (for all later processes/threads). Do you
think it's a viable idea?

-- 
You are receiving this mail because:
You are the assignee for the bug.