Re: [PATCH v43 00/15] /dev/random - a new approach

From: Thomas Schoebel-Theuer
Date: Sat Dec 11 2021 - 10:58:09 EST


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.