lkml.org 
[lkml]   [2021]   [Dec]   [11]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    SubjectRe: [PATCH v43 00/15] /dev/random - a new approach
    From
    Date
    On 11/21/21 5:39 PM, Stephan Müller wrote:
    > The following patch set provides a complete production-
    > ready and yet different approach to /dev/random which is called Linux
    > Random Number Generator (LRNG) to collect entropy within the Linux kernel.
    > It provides the same API and ABI and can be used as a drop-in replacement.

    My suggestion: please name it /dev/fastrandom or /dev/fips-random or
    /dev/scalable-random or whatever is appropriate, and please leave the
    traditional /dev/random as it was for decades.

    My reasons:

    I am one of the downstream kernel responsibles you might affect with
    your changes. I am responsible for any kernel issues for millions of
    customers.

    For me, the _slowness_ of the traditional /dev/random is a _feature_.

    Some more detailed arguments, important for my use cases as seen by me:

    1) Personally, I have made some 1&1-internal scripts which don't rely on
    a single source of entropy, as seen by sysadmins. Note that each
    /dev/$other_random is a _single_ _source_ of entropy from a sysadmin's
    perspective (and also a "blackbox"), although the role is different from
    a kernel developer's perspective.

    2) Any new kernel must be able to run on any of our machines, even very
    old machines (bound by old customer contracts) which don't have certain
    hardware features, or have a different non-functional behaviour like
    performance, or interrupt timing behaviour, etc. Thus the non-functional
    behaviour of the traditional /dev/random is important for me. Please do
    not change it.

    3) Whenever a new kernel behaviour is "discovered" by some userspace
    developers (whether in-house or from many OpenSource projects around the
    world), they tend to use it sooner or later, for whatever reason. If
    suchalike would happen at the traditional /dev/random, it would be
    noticed by some of our sysadmin teams. Here is the reason:

    4) Collection of entropy vs consumption of entropy: the old /dev/random
    has an important feature for me: any _mass_ usage by whatever class of
    users (whether tenthousands of UIDs per server and/or HTTP/second, or
    maybe even some privileged orchestration scripts) would _consume_ masses
    of entropy. When suchalike consumption would exceed the production rate,
    the old /dev/random would become so slow that our internal monitoring
    processes would certainly alert, and consequently would hint our
    responsibles (located at other teams) at the problem. Traditionally,
    /dev/random and /dev/urandom are thus used for different purposes.

    5) Please don't misunderstand me: I am _not_ against the bazaar model
    which allows you to develop new and interesting features. Just don't
    throw away the traditional solutions, encapsulating huge amounts of
    manpower. Please create a new booth at the bazaar. Then some hundreds of
    userspace developers can support the new solution, or even  migrate from
    traditional interfaces like /dev/urandom to newer ones. Many userspace
    projects are widely distributed, and independent from each other. By
    providing a different interface (which is easily detectable), separation
    of concerns will become easy in a worldwide scale.

    Hints: whenever changing / improving non-functional properties of your
    new /dev/$new_random, please report _separate_ version numbers for
    non-functional vs feature versions. Please maintain it over many years
    (hopefully comparable to the lifetime of /dev/random). Please long-term
    document the rules how its new features should be _interpreted_. Please
    document important use cases. Please create a better documentation than
    the traditional ones, also understandable by sysadmins (not only by
    certain developers or security experts). Even more important: please
    document and depict _scenarios_ where certain features should _NOT_ be used.

    Cheers and very sincerly,

    Thomas

    Homepage: https://github.com/schoebel and look into the mars/ project
    and also into its docu/ subfolder. Please read the big pdfs. Then you
    might notice that I could become a potential future user of your new code.

    \
     
     \ /
      Last update: 2021-12-11 16:58    [W:4.075 / U:0.080 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site