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

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=262192

--- 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 early
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, accidental
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 processes/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, rewriting
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 kernel's
stack guards.  (Intuitively, leaking the kernel stack guards to userspace
processes would kind of defeat the point of having unpredictable kernel stack
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 to 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

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