Date: Mon, 28 Feb 2022 17:37:08 +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-Dw76wQmZjk@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 #6 from Conrad Meyer <cem@freebsd.org> --- (In reply to Olivier Certner from comment #5) Hi Olivier, Yes, the CSPRNG subsystem is not really designed to be usable from very ear= ly in boot with a read-only image, with the various problems you accurately describe. As far as uncovering stack overflow bugs: doesn't a system without stack cookies also work to uncover stack overflow bugs? Most of the time, accide= ntal corruption of the return address will also crash the process. > Don't know the inner details of SSP, but is the same guard used for all p= rocesses/threads? The initialization described in this bug is only for the kernel's stack cookies. The kernel is essentially a privileged process that lives for the entire boot. As far as I know, there is no way to safely change the stack guard cookie values of the running kernel. (I imagine you would have to suspend all cores, including interrupts, and walk all thread stacks, rewrit= ing the cookies. Or add a layer of indirection to stack check failures.) Userspace initializes __stack_chk_guard in lib/libc/secure/stack_protector.= c, from the AT_CANARY auxinfo. Auxinfo is initialized in sys/kern/imgact_elf.c from imgp->canary. For FreeBSD processes (Linuxemul differs), canary is initialized in sys/kern/kern_exec.c by arc4rand(9). In short, userspace processes are seeded with their own stack guards based = on the best random available when they are started -- not a clone of the kerne= l's stack guards. (Intuitively, leaking the kernel stack guards to userspace processes would kind of defeat the point of having unpredictable kernel sta= ck guards. And shared userspace stack guards between processes would also somewhat defeat the point of having unpredictable stack guards.) I think the most satisfying directions for you to pursue are likely going t= o be (1) static kernel stack guards, if you can live with that and if that is the only early random request blocking boot or (2) implementing early on-demand seeding in one of the ways discussed in comment #4. Best, Conrad --=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-Dw76wQmZjk>