If you don't use all the interlocked openbsd pieces together, and replace some of them with your own, then you take on responsibility for the problems we didn't need to solve because they don't exist in our complete solution.
I think that is pretty simple. I hope you understand. As such, I have no comments on the rest of your questions, because in our complete model, those questions don't matter. I'm not kidding. tetrahe...@danwin1210.me wrote: > On Thu, Oct 21, 2021 at 03:46:20PM +0200, Janne Johansson wrote: > >https://marc.info/?l=openbsd-tech&m=138829898720574&w=2 > >and > >https://marc.info/?l=openbsd-tech&m=139013674405106&w=2 > >might help. > > Thanks. This is the critical section: > https://github.com/openbsd/src/blob/9c70cf5498e471044289f4c9857b84b309c5964e/sys/dev/rnd.c#L44-L45 > > So if the volume with the bootloader on it is not booted, the RNG is > intialised with a less-random value (in particular if a hardware RNG is > not present). > > On Linux it's possible to check for an Intel hardware RNG[1] by looking > for `rdrand` in /proc/cpuinfo[2]. *BSD seems to split this across > `sysctl hw`, dmesg, and `dmidecode` [3]. > > Does this sound right -- will OpenBSD use the `rdrand` instruction if > present, early in the boot process? > > [1] > https://stackoverflow.com/questions/26771329/is-there-any-legitimate-use-for-intels-rdrand > > [2] > https://0f5f.blogs.minster.io/2015/10/leveraging-intel-ivy-bridges-hardware-rng/ > > [3] > https://stackoverflow.com/questions/4083848/what-is-the-equivalent-of-proc-cpuinfo-on-freebsd-v8-1 >
