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

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.