lkml.org 
[lkml]   [2019]   [Sep]   [19]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    From
    SubjectRe: Linux 5.3-rc8
    Date
    Dear Lennart.

    Lennart Poettering - 18.09.19, 15:53:25 CEST:
    > On Mi, 18.09.19 00:10, Martin Steigerwald (martin@lichtvoll.de) wrote:
    > > > getrandom() will never "consume entropy" in a way that will block
    > > > any
    > > > users of getrandom(). If you don't have enough collected entropy
    > > > to
    > > > seed the rng, getrandom() will block. If you do, getrandom() will
    > > > generate as many numbers as you ask it to, even if no more entropy
    > > > is
    > > > ever collected by the system. So it doesn't matter how many
    > > > clients
    > > > you have calling getrandom() in the boot process - either there'll
    > > > be
    > > > enough entropy available to satisfy all of them, or there'll be
    > > > too
    > > > little to satisfy any of them.
    > >
    > > Right, but then Systemd would not use getrandom() for initial
    > > hashmap/ UUID stuff since it
    >
    > Actually things are more complex. In systemd there are four classes of
    > random values we need:
    >
    > 1. High "cryptographic" quality. There are very few needs for this in
    […]
    > 2. High "non-cryptographic" quality. This is used for example for
    […]
    > 3. Medium quality. This is used for seeding hash tables. These may be
    […]
    > 4. Crap quality. There are only a few uses of this, where rand_r() is
    > is OK.
    >
    > Of these four case, the first two might block boot. Because the first
    > case is not common you won't see blocking that often though for
    > them. The second case is very common, but since we use RDRAND you
    > won't see it on any recent Intel machines.
    >
    > Or to say this all differently: the hash table seeding and the uuid
    > case are two distinct cases in systemd, and I am sure they should be.

    Thank you very much for your summary of uses of random numbers in
    Systemd and also for your other mail that "neither RDRAND nor /dev/
    urandom know a concept of of "depleting entropy"". I thought they would
    deplete entropy needed to the initial seeding of crng.

    Thank you also for taking part in this discussion, even if someone put
    your mail address on carbon copy without asking with.

    I do not claim I understand enough of this random number stuff. But I
    feel its important that kernel and userspace developers actually talk
    with each other about a sane approach for it. And I believe that the
    complexity involved is part of the issue. I feel an API for attaining
    random number with different quality levels needs to be much, much, much
    more simple to use *properly*.

    I felt a bit overwhelmed by the discussion (and by what else is
    happening in my life, just having come back from holding a Linux
    performance workshop in front of about two dozen people), so I intend to
    step back from it.

    If one of my mails actually helped to encourage or facilitate kernel
    space and user space developers talking with each other about a sane
    approach to random numbers, then I may have used my soft skills in a way
    that brings some benefit. For the technical aspects certainly people are
    taking part in this discussion who are much much deeper into the
    intricacies of entropy in Linux and computers in general, so I just hope
    for a good outcome.

    Best,
    --
    Martin


    \
     
     \ /
      Last update: 2019-09-19 09:29    [W:2.065 / U:0.204 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site