Re: [PATCH v25 10/12] LRNG - add TRNG support

[Stephan Mueller <smueller@chronox.de>]

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 <smueller@chronox.de> wrote:
> > Am Samstag, 16. November 2019, 17:09:09 CET schrieb Andy Lutomirski:
> > 
> > Hi Andy,
> > 
> > > > On Nov 16, 2019, at 1:40 AM, Stephan Müller <smueller@chronox.de>
> > > > 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).
> > > 
> > > ...
> > > 
> > > > 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.
> 
> > 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