On Sun, 16 Aug 2020 at 08:13, Martin Husemann <mar...@duskware.de> wrote: > > Hi Nia, > > I think you are mixing a few issues here into one discussion - which might > make sense from a user perspective, but does not help us to get forward.
I think that the other issues provide important context. NetBSD's underlying implementation has a fundamental difference in blocking entropy behaviour - the specification matches in terms of "an implementation *may* block... ", but real world use will have some NetBSD boxes block indefinitely until user intervention, whereas other systems would not. Obviously there is no perfect choice, as other different systems have made different API behaviour choices, and in general have a less sophisticated approach to entropy usage, and NetBSD itself has to cater for boxes with and without hardware entropy. However a getentropy() where the *effective* behaviour from a user perspective matched Linux and the other BSDs but not Solaris would seem to be a reasonable option. As the Linux random(7) manpage even suggests "The getentropy(3) function provides a slightly more portable interface on top of getrandom(2)" David > From my POV the interacting-but-need-to-be-solved-individually issues > are: > > - The libc or kernel<->userland API. This is what the core decision was > about. The API is well (enough) defined, same on multiple OSes, > and provides all the flexibility we need. > > - Making entropy available "early enough" during the boot process. This > is a hard problem on *many* machines, but no big deal at all on modern > x86 and a few modern aarch64. > For me this is looks like still work in progress with no "good enough" > solution yet. I understood Taylor would like to improve this next. > I personally would define "early enough" as "during rc.d" and this makes > the problem relatively easily solvable for "real installations" (see > below) by just manually (or "someway") seeding the individual installations > entropy file. > IIUC Taylor would like to also enhance/add kernel parts providing entropy. > > - Related to above: how to deal with one-off setups like first boots of > install images or clones of virtual machines. > This will be solvable (probably by a combination of better scripting > and/or documented "best practices") once the point above is more or > less settled. > > - Finaly the grey area of "which variant of our API should applications > use" (and even more complex: libraries). This needs individual answers > on a case by case basis and might need some upstream battle - but we > should be able to give good guidance and clear rules once the items > above are cleared. > > Martin
