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

From: <bugzilla-noreply_at_freebsd.org>
Date: Sat, 26 Feb 2022 00:39:12 UTC
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=262192

Conrad Meyer <cem@freebsd.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
              Flags|maintainer-feedback?(cem@fr |
                   |eebsd.org)                  |

--- Comment #4 from Conrad Meyer <cem@freebsd.org> ---
I'm not really sure why tsleep() is panicing at that point.  Presumably that
initialization happens later in mi_startup.

Your virtual hardware plus operating system configuration is resulting in a
system that is not seeded by the time mi_startup hits __stack_chk_init
(SI_SUB_RANDOM:SI_ORDER_ANY).  This means that the system did not have any
bootloader entropy (SI_SUB_RANDOM:SI_ORDER_FOURTH).

__stack_chk_init happens very early, before random_kthread can run.  So the
system hasn't polled any "devices" for entropy, including RDRAND.

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.)  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.  Third option is to set
kern.random.initial_seeding.bypass_before_seeding=1.

Could this be better?  Sure.  Chacha20_randomstir and/or read_random could
attempt to manually poll available random sources (assuming any are loaded and
available!) during early boot if not yet seeded, or fetch jitter entropy (maybe
not this early, though -- if tsleep is broken, jitter might be as well).  Kyle
Evans has expressed some interest in working on the latter.  tsleep() could
detect early boot and not panic instead of taking whatever uninitialized lock
it's taking.  I don't plan to do any of that.

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