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: <5032854.qLNvD48x4y@positron.chronox.de>
Date:   Thu, 21 Nov 2019 14:06:03 +0100
From:   Stephan Müller <smueller@...onox.de>
To:     Greg Kroah-Hartman <gregkh@...uxfoundation.org>
Cc:     Andy Lutomirski <luto@...nel.org>, Arnd Bergmann <arnd@...db.de>,
        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 Mittwoch, 20. November 2019, 21:32:32 CET schrieb Greg Kroah-Hartman:

Hi Greg,

> No, do not abuse sysfs or procfs for something like this.  Use a real
> syscall please if you really need it.

You are right.

Ok, let us get back to the drawing board. What are our requirements? We need 
to have an interface for the TRNG that should ensure other users of entropy 
are not starved by unprivileged users.

What about the following: we use the getrandom(2) system call and add 
GRND_TRUERANDOM as already indicated. However, there is one more caveat we 
would add:

- if the caller of GRND_TRUERANDOM is !CAP_SYS_ADMIN the entropy pool can only 
be depleted to the point where at least one or two full seeding operations 
worth of entropy is left.

- if the caller of GRND_TRUERANDOM is CAP_SYS_ADMIN, the entropy can be 
depleted completely

At runtime, the LRNG would then behave like the following:

- calling getrandom(..., 0), /dev/random or /dev/urandom would deplete the 
entropy pool during reseeding operations but leaving an emergency level of 512 
bits of entropy in the pool. If equal or less are in the pool, reseeding would 
be skipped.

- calling getrandom(..., GRND_TRUERANDOM) with CAP_SYS_ADMIN allows the 
entropy pool to be fully depleted.

- calling getrandom(..., GRND_TRUERANDOM) without CAP_SYS_ADMIN allows the 
entropy pool to be depleted down to 1024 bits of entropy. If the pool has 
equal or less, the caller is blocked. This allows the DRNG feeding /dev/
random, /dev/urandom or getrandom(..., 0) with 512 bits of entropy (i.e. two 
reseed operations are possible). Only if the entropy pool has more than 1024 
bits of entropy, the getrandom call would unblock and provide data.

With that approach, I think we can honor the request from Greg to not add any 
new interface and yet honor the note from Alexander to not allow unprivileged 
user space to deplete the entropy pool to the extent that other users of 
entropy are too much affected.

If GRND_TRUERANDOM is not implemented, EOPNOTSUPP is returned.

Thank you.

Ciao
Stephan