svn commit: r346250 - in head: share/man/man4 share/man/man9 sys/dev/random sys/kern sys/libkern sys/sys

[Conrad Meyer]

Hi Ruslan,

On Tue, Apr 16, 2019 at 8:38 AM Ruslan Bukin <br at bsdpad.com> wrote:
>
> Hi I just got this:
>
> ...
> _sleep() at random_harvest_deregister_source+0x132
> random_harvest_deregister_source() at read_random+0xc4
> read_random() at vn_fsync_buf+0x594
> vn_fsync_buf() at arc4rand+0xd4
> arc4rand() at sched_tdname+0x4c
> sched_tdname() at mi_startup+0x20c
> mi_startup() at 0xffffffc0000001a6
> KDB: enter: panic


The stack is clearly bogus or missing some frames; can you attach GDB
on this system (or an emulator) and get a full stack?  The step(s) I'm
missing are mi_startup -> sched_tdname, and sched_tdname ->
arc4rand().  What's consuming random during early boot on riscv?

(The vn_fsync_buf frame is also confusing and probably incorrect?  A
real stack would be helpful.)  Maybe it's just __stack_chk_init, given
mi_startup, like the other reproductions.  I will need to take a step
back from email to address that.)

> We don't have loader(8) support for RISC-V and we don't have any hardware with random number generators yet. Most of our fpga/hardware has no way to have rootfs at all (we use mdroot).

Is it possible to inject entropy into the mdroot?  If not, it seems
like anything that consumes random during early boot on riscv must be
disabled.

> We use BBL bootloader to boot freebsd. BBL embeds freebsd kernel to the BBL binary on a compile time (similar way how we embed mdroot to kernel). Once BBL initialized itself it jumps to the pre-defined address of payload which is freebsd kernel.
>
> So I'm pondering what is our current option, i.e. how to feed entropy in this case ?

Can a running system rebuild the mdroot or BBL?  Or do they reside on
RO flash of some kind?  If so, it would be possible to rewrite the BBL
or mdroot with entropy injected for the next boot, I think.

Otherwise, the straightforward solution is to simply disable anything
that attempts to consume random early in boot on such devices with no
hardware entropy source and no early filesystem access.

Anything that is tripping on this was silently feeding itself with
predictable, non-random data prior to this change.

Best,
Conrad