Date: Sat, 26 Feb 2022 00:39:12 +0000 From: bugzilla-noreply@freebsd.org To: bugs@FreeBSD.org Subject: [Bug 262192] Crashes at boot with kern.random.initial_seeding.bypass_before_seeding=0 in randomdev_wait_until_seeded() Message-ID: <bug-262192-227-DJYRHE7oJC@https.bugs.freebsd.org/bugzilla/> In-Reply-To: <bug-262192-227@https.bugs.freebsd.org/bugzilla/> References: <bug-262192-227@https.bugs.freebsd.org/bugzilla/>
next in thread | previous in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D262192 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 whate= ver) 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=3D1. This is practically s= imilar to not compiling in stackcookies at all. Third option is to set kern.random.initial_seeding.bypass_before_seeding=3D1. 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 (m= aybe not this early, though -- if tsleep is broken, jitter might be as well). K= yle Evans has expressed some interest in working on the latter. tsleep() could detect early boot and not panic instead of taking whatever uninitialized lo= ck it's taking. I don't plan to do any of that. --=20 You are receiving this mail because: You are the assignee for the bug.=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-262192-227-DJYRHE7oJC>