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)"


> 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

Reply via email to