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.
