From: "Theodore Y. Ts'o" <tytso@mit.edu> To: Kurt Roeckx <kurt@roeckx.be> Cc: Stephan Mueller <smueller@chronox.de>, Andy Lutomirski <luto@amacapital.net>, Andy Lutomirski <luto@kernel.org>, LKML <linux-kernel@vger.kernel.org>, Linux API <linux-api@vger.kernel.org>, Kees Cook <keescook@chromium.org>, "Jason A. Donenfeld" <Jason@zx2c4.com>, "Ahmed S. Darwish" <darwish.07@gmail.com>, Lennart Poettering <mzxreary@0pointer.de>, "Eric W. Biederman" <ebiederm@xmission.com>, "Alexander E. Patrakov" <patrakov@gmail.com>, Michael Kerrisk <mtk.manpages@gmail.com>, Willy Tarreau <w@1wt.eu>, Matthew Garrett <mjg59@srcf.ucam.org>, Ext4 Developers List <linux-ext4@vger.kernel.org>, linux-man <linux-man@vger.kernel.org> Subject: Re: [PATCH v3 0/8] Rework random blocking Date: Thu, 9 Jan 2020 17:40:11 -0500 [thread overview] Message-ID: <20200109224011.GD41242@mit.edu> (raw) In-Reply-To: <20200109220230.GA39185@roeckx.be> On Thu, Jan 09, 2020 at 11:02:30PM +0100, Kurt Roeckx wrote: > > One thing the NIST DRBGs have is prediction resistance, which is > done by reseeding. If you chain DRBGs, you tell your parent DRBG > that you want prediction resistance, so your parent will also > reseed. There currently is no way to tell the kernel to reseed. It would be simple enough to add a new flag, perhaps GRND_RESEED, to getrandom() which requests that the kernel reseed first. This would require sufficient amounts of entropy in the input pool to do the reseed; if there is not enough, the getrandom() call would block until there was enough. If GRND_NONBLOCK is supplied, then getrandom() would return EAGAIN if there wasn't sufficient entropy. Is this what you want? What should happen if two racing processes simultaneously call getrandom(2) with GRND_RESEED? Do they need to be serialized with a separate reseed for each one? Does it matter whether, after the reseed, some other process calling getrandom(2) manages to get output from the CRNG before the process requesting the RESEED gets a chance to use the reseeded CRNG? This can all be fixed by adding more locking, of course, but then the crazy people who think that: dd if=/dev/random of=/dev/sdb needs to be able to work at HDD, SSD, or networking line speeds, will complain that all of this locking has slowed down /dev/[u]random, and they can't get their hundreds of megabytes/second out of the CRNG.... > I would check my own hardware if such an option was available. I > think it can be useful to see if the current estimates in the > kernel are conservative enough or not. But it would require that > you can know what the entropy source is, like the keyboard or > harddisk. Creating such an interface is not high on my priority list. If someone wants to send a proposal for such an interface, followed by a patch, I'm happy to take a look at it. I am worried about the potential information leakage that such an interface might provide, though. So at the very least, it should be something that can be disabled via build-time config, and perhaps hidden behind CONFIG_EXPERIMENTAL. I really would want to make it clear that it's only for use by experts who are interesting in tinkering, and not something which is enabled in a distro kernel. > I don't think we want that. As far as I know, the only reason for > using /dev/random is that /dev/urandom returns data before it > has sufficient entropy. Is there any objections to just using getrandom(2)? - Ted
WARNING: multiple messages have this Message-ID (diff)
From: "Theodore Y. Ts'o" <tytso-3s7WtUTddSA@public.gmane.org> To: Kurt Roeckx <kurt-burXGKnpAKGzQB+pC5nmwQ@public.gmane.org> Cc: Stephan Mueller <smueller-T9tCv8IpfcWELgA04lAiVw@public.gmane.org>, Andy Lutomirski <luto-kltTT9wpgjJwATOyAt5JVQ@public.gmane.org>, Andy Lutomirski <luto-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>, LKML <linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>, Linux API <linux-api-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>, Kees Cook <keescook-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org>, "Jason A. Donenfeld" <Jason-OnJsPKxuuEcAvxtiuMwx3w@public.gmane.org>, "Ahmed S. Darwish" <darwish.07-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>, Lennart Poettering <mzxreary-uLTowLwuiw4b1SvskN2V4Q@public.gmane.org>, "Eric W. Biederman" <ebiederm-aS9lmoZGLiVWk0Htik3J/w@public.gmane.org>, "Alexander E. Patrakov" <patrakov-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>, Michael Kerrisk <mtk.manpages-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>, Willy Tarreau <w@1wt.eu>, Matthew Garrett <mjg59-1xO5oi07KQx4cg9Nei1l7Q@public.gmane.org>, Ext4 Developers List <linux-ext4-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>, linux-man <linux-man-u79uwXL29TY76Z2rM5mHXA@public.gmane.org> Subject: Re: [PATCH v3 0/8] Rework random blocking Date: Thu, 9 Jan 2020 17:40:11 -0500 [thread overview] Message-ID: <20200109224011.GD41242@mit.edu> (raw) In-Reply-To: <20200109220230.GA39185-burXGKnpAKGzQB+pC5nmwQ@public.gmane.org> On Thu, Jan 09, 2020 at 11:02:30PM +0100, Kurt Roeckx wrote: > > One thing the NIST DRBGs have is prediction resistance, which is > done by reseeding. If you chain DRBGs, you tell your parent DRBG > that you want prediction resistance, so your parent will also > reseed. There currently is no way to tell the kernel to reseed. It would be simple enough to add a new flag, perhaps GRND_RESEED, to getrandom() which requests that the kernel reseed first. This would require sufficient amounts of entropy in the input pool to do the reseed; if there is not enough, the getrandom() call would block until there was enough. If GRND_NONBLOCK is supplied, then getrandom() would return EAGAIN if there wasn't sufficient entropy. Is this what you want? What should happen if two racing processes simultaneously call getrandom(2) with GRND_RESEED? Do they need to be serialized with a separate reseed for each one? Does it matter whether, after the reseed, some other process calling getrandom(2) manages to get output from the CRNG before the process requesting the RESEED gets a chance to use the reseeded CRNG? This can all be fixed by adding more locking, of course, but then the crazy people who think that: dd if=/dev/random of=/dev/sdb needs to be able to work at HDD, SSD, or networking line speeds, will complain that all of this locking has slowed down /dev/[u]random, and they can't get their hundreds of megabytes/second out of the CRNG.... > I would check my own hardware if such an option was available. I > think it can be useful to see if the current estimates in the > kernel are conservative enough or not. But it would require that > you can know what the entropy source is, like the keyboard or > harddisk. Creating such an interface is not high on my priority list. If someone wants to send a proposal for such an interface, followed by a patch, I'm happy to take a look at it. I am worried about the potential information leakage that such an interface might provide, though. So at the very least, it should be something that can be disabled via build-time config, and perhaps hidden behind CONFIG_EXPERIMENTAL. I really would want to make it clear that it's only for use by experts who are interesting in tinkering, and not something which is enabled in a distro kernel. > I don't think we want that. As far as I know, the only reason for > using /dev/random is that /dev/urandom returns data before it > has sufficient entropy. Is there any objections to just using getrandom(2)? - Ted
next prev parent reply other threads:[~2020-01-09 22:41 UTC|newest] Thread overview: 43+ messages / expand[flat|nested] mbox.gz Atom feed top 2019-12-23 8:20 [PATCH v3 0/8] Rework random blocking Andy Lutomirski 2019-12-23 8:20 ` [PATCH v3 1/8] random: Don't wake crng_init_wait when crng_init == 1 Andy Lutomirski 2020-01-07 20:42 ` Theodore Y. Ts'o 2019-12-23 8:20 ` [PATCH v3 2/8] random: Add a urandom_read_nowait() for random APIs that don't warn Andy Lutomirski 2020-01-07 20:43 ` Theodore Y. Ts'o 2019-12-23 8:20 ` [PATCH v3 3/8] random: Add GRND_INSECURE to return best-effort non-cryptographic bytes Andy Lutomirski 2020-01-07 20:44 ` Theodore Y. Ts'o 2019-12-23 8:20 ` [PATCH v3 4/8] random: Ignore GRND_RANDOM in getentropy(2) Andy Lutomirski 2020-01-07 20:44 ` Theodore Y. Ts'o 2019-12-23 8:20 ` [PATCH v3 5/8] random: Make /dev/random be almost like /dev/urandom Andy Lutomirski 2020-01-07 21:02 ` Theodore Y. Ts'o 2019-12-23 8:20 ` [PATCH v3 6/8] random: Remove the blocking pool Andy Lutomirski 2020-01-07 21:03 ` Theodore Y. Ts'o 2019-12-23 8:20 ` [PATCH v3 7/8] random: Delete code to pull data into pools Andy Lutomirski 2020-01-07 21:03 ` Theodore Y. Ts'o 2019-12-23 8:20 ` [PATCH v3 8/8] random: Remove kernel.random.read_wakeup_threshold Andy Lutomirski 2020-01-07 21:04 ` Theodore Y. Ts'o 2019-12-26 9:29 ` [PATCH v3 0/8] Rework random blocking Stephan Müller 2019-12-26 10:03 ` Matthew Garrett 2019-12-26 11:40 ` Stephan Mueller 2019-12-26 11:12 ` Andy Lutomirski 2019-12-26 12:03 ` Stephan Mueller 2019-12-26 12:46 ` Andy Lutomirski 2019-12-27 9:55 ` Stephan Mueller 2019-12-26 14:04 ` Theodore Y. Ts'o 2019-12-26 23:29 ` Andy Lutomirski 2019-12-27 10:29 ` Stephan Mueller 2019-12-27 13:04 ` Theodore Y. Ts'o 2019-12-27 21:22 ` Stephan Mueller 2019-12-27 22:08 ` Theodore Y. Ts'o 2019-12-28 2:06 ` Andy Lutomirski 2019-12-29 14:49 ` Theodore Y. Ts'o 2019-12-29 15:08 ` Andy Lutomirski 2019-12-28 7:01 ` Willy Tarreau 2020-01-09 22:02 ` Kurt Roeckx 2020-01-09 22:02 ` Kurt Roeckx 2020-01-09 22:40 ` Theodore Y. Ts'o [this message] 2020-01-09 22:40 ` Theodore Y. Ts'o 2020-01-09 23:02 ` Kurt Roeckx 2020-01-09 23:02 ` Kurt Roeckx 2020-01-10 7:53 ` Stephan Mueller 2020-01-10 7:53 ` Stephan Mueller 2020-01-10 0:30 ` Andy Lutomirski
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=20200109224011.GD41242@mit.edu \ --to=tytso@mit.edu \ --cc=Jason@zx2c4.com \ --cc=darwish.07@gmail.com \ --cc=ebiederm@xmission.com \ --cc=keescook@chromium.org \ --cc=kurt@roeckx.be \ --cc=linux-api@vger.kernel.org \ --cc=linux-ext4@vger.kernel.org \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-man@vger.kernel.org \ --cc=luto@amacapital.net \ --cc=luto@kernel.org \ --cc=mjg59@srcf.ucam.org \ --cc=mtk.manpages@gmail.com \ --cc=mzxreary@0pointer.de \ --cc=patrakov@gmail.com \ --cc=smueller@chronox.de \ --cc=w@1wt.eu \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.