linux-kernel - Re: [PATCH v25 10/12] LRNG

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <25235737.Vo4cOZQZay@tauon.chronox.de>
Date:   Tue, 19 Nov 2019 11:46:51 +0100
From:   Stephan Mueller <smueller@...onox.de>
To:     Andy Lutomirski <luto@...nel.org>
Cc:     Arnd Bergmann <arnd@...db.de>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Linux Crypto Mailing List <linux-crypto@...r.kernel.org>,
        LKML <linux-kernel@...r.kernel.org>,
        Linux API <linux-api@...r.kernel.org>,
        "Eric W. Biederman" <ebiederm@...ssion.com>,
        "Alexander E. Patrakov" <patrakov@...il.com>,
        "Ahmed S. Darwish" <darwish.07@...il.com>,
        "Theodore Y. Ts'o" <tytso@....edu>, Willy Tarreau <w@....eu>,
        Matthew Garrett <mjg59@...f.ucam.org>,
        Vito Caputo <vcaputo@...garu.com>,
        Andreas Dilger <adilger.kernel@...ger.ca>,
        Jan Kara <jack@...e.cz>, Ray Strode <rstrode@...hat.com>,
        William Jon McCann <mccann@....edu>,
        zhangjs <zachary@...shancloud.com>,
        Florian Weimer <fweimer@...hat.com>,
        Lennart Poettering <mzxreary@...inter.de>,
        Nicolai Stange <nstange@...e.de>,
        "Peter, Matthias" <matthias.peter@....bund.de>,
        Marcelo Henrique Cerri <marcelo.cerri@...onical.com>,
        Roman Drahtmueller <draht@...altsekun.de>,
        Neil Horman <nhorman@...hat.com>
Subject: Re: [PATCH v25 10/12] LRNG - add TRNG support

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@...onox.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@...onox.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