Am Dienstag, 19. November 2019, 11:07:40 CET schrieb Andy Lutomirski:

Hi Andy,

On Sun, Nov 17, 2019 at 3:11 AM Stephan Müller [off-list ref] wrote:

quoted

Am Samstag, 16. November 2019, 17:09:09 CET schrieb Andy Lutomirski:

Hi Andy,

quoted

quoted

On Nov 16, 2019, at 1:40 AM, Stephan Müller [off-list ref]
wrote:

The True Random Number Generator (TRNG) provides a random number
generator with prediction resistance (SP800-90A terminology) or an
NTG.1
(AIS 31 terminology).

...

quoted

The secondary DRNGs seed from the TRNG if it is present. In addition,
the /dev/random device accesses the TRNG.

If the TRNG is disabled, the secondary DRNGs seed from the entropy
pool
and /dev/random behaves like getrandom(2).

As mentioned before, I don’t like this API.  An application that, for
some
reason, needs a TRNG, should have an API by which it either gets a TRNG
or
an error. Similarly, an application that wants cryptographically secure
random numbers efficiently should have an API that does that.  With your
design, /dev/random tries to cater to both use cases, but one of the use
cases fails depending on kernel config.

I think /dev/random should wait for enough entropy to initialize the
system
but should not block after that. A TRNG should have an entirely new API
that is better than /dev/random.

I apologize for the misunderstanding. I assumed we would introduce such
/dev/ true_random at a later stage.

If you agree, I can certainly add /dev/true_random right now that links
with the TRNG and make /dev/random behave as discussed, i.e. behave
exactly like getrandom(..., 0);

Given that your series is already a decently large ABI change, I think
it would be polite to users to make all the anticipated changes all at
once to reduce the amount of churn everyone needs to deal with.

I fully agree with that. This is the reason for my question to ask for how to 
approach adding such additional interface for the TRNG. Considering that there 
are use cases for the blocking interfaces, I would like to have it present 
from the start.

That said, are you planning to keep the blocking_pool considering our 
discussion?

But may I ask why you say that there are ABI changes? The LRNG set tries to be 
100% API and ABI compliant to the existing random.c interfaces.

The only change is the runtime-behavior (e.g. time when something is seeded), 
performance of the interrupt handling and the kernel/user interfaces that may 
be noticeable by users. I.e. there are timing changes, but no technical 
changes.

The LRNG though would add one optional interface for kernel internal use and 
then the discussed /dev/true_random interface.

quoted

As this would introduce a new device file now, is there a special process
that I need to follow or do I need to copy? Which major/minor number
should I use?

Looking into static const struct memdev devlist[] I see

         [8] = { "random", 0666, &random_fops, 0 },
         [9] = { "urandom", 0666, &urandom_fops, 0 },

Shall a true_random be added here with [10]?

I am not at all an expert on chardevs, but this sounds generally
reasonable.  gregkh is probably the real authority here.

Thank you for the hint. Then I would like to wait for Greg on this.

Ciao
Stephan