Date: Wed, 09 Mar 2022 21:35:21 +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-yggM8n7KXi@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 --- Comment #10 from Olivier Certner <olivier.freebsd@free.fr> --- (In reply to Conrad Meyer from comment #9) Forgot to mention the example of domain init causing a call to arc4rand() I stumbled upon: ip_init =3D> ip_reass, which initializes some hash seed that serves to hash fragments. I suspect the goal here is to make it hard for an attacker to predict which frags end up in which bucket, so that it cannot degrade the hash table's access performance without a more involved attack. Probably this could be avoided by using another, more complex, data structu= re. Maybe simply delaying this seed's init is possible. > If you want to pursue it, identifying the stack(s) blocking on random and > moving them after KICK_SCHEDULER would be a valuable contribution to Free= BSD. I'll try to pursue that indeed, by recompiling a kernel with a deterministic frag seed, and see what other calls to random exist. In the end, it might n= ot be possible to easily push calls to random after KICK_SCHEDULER without more involved changes. We'll see. Don't have much time now, but expect to have a lot in approx two months. Th= en, the ability to boot without an entropy seed file should be one of my main priorities. In the meantime, I'll report about experiments here. Thanks. --=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-yggM8n7KXi>