[Bug 262192] Crashes at boot with kern.random.initial_seeding.bypass_before_seeding=0 in randomdev_wait_until_seeded()
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.