From: Andy Lutomirski <luto@amacapital.net>
To: Mark Kettenis <mark.kettenis@xs4all.nl>, Theodore Ts'o <tytso@mit.edu>
Cc: linux-kernel@vger.kernel.org, linux-crypto@vger.kernel.org,
beck@openbsd.org
Subject: Re: [PATCH, RFC] random: introduce getrandom(2) system call
Date: Thu, 17 Jul 2014 13:35:15 -0700 [thread overview]
Message-ID: <53C83383.4040507@amacapital.net> (raw)
In-Reply-To: <201407171848.s6HImBb4027900@glazunov.sibelius.xs4all.nl>
On 07/17/2014 11:48 AM, Mark Kettenis wrote:
> On Thu, Jul 17, 2014, Theodore Ts'o wrote:
>>
>> The getrandom(2) system call is a superset of getentropy(2). When we
>> add the support for this into glibc, it won't be terribly difficult
>> nor annoying to drop the following in alongside the standard support
>> needed for any new system call:
>>
>> int getentropy(void *buf, size_t buflen)
>> {
>> int ret;
>>
>> ret = getentropy(buf, buflen, 0);
>> return (ret > 0) ? 0 : ret;
>> }
>
> I'm sure you meant to use getrandom() there ;)
>
> Since for LibreSSL we'd want a getentropy() that cannot fail the
> getrandom() call should use GRND_BLOCK flag. Actually it makes sense
> (to me) to make blocking the default behaviour and have a
> BRND_NONBLOCK flag. Much in the same way as you need to specify
> O_NONBLOCK if you want non-blocking behaviour for files.
>
Can we please have a mode in which getrandom(2) can neither block nor
fail? If that gets added, then this can replace things like AT_RANDOM.
There are non-crypto things out there that will want this. There are
also probably VM systems (especially ones that have something like my
KVM_GET_RNG_SEED patches applied, or many VMs on Haswell, for that
matter) that will have perfectly fine cryptographically secure urandom
output immediately after bootup but that won't consider themselves
"initialized" for a while. At least these will be perfectly fine from
the POV of those who trust their hypervisor and Intel :)
--Andy
next prev parent reply other threads:[~2014-07-17 20:35 UTC|newest]
Thread overview: 57+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-07-17 18:48 [PATCH, RFC] random: introduce getrandom(2) system call Mark Kettenis
2014-07-17 20:35 ` Andy Lutomirski [this message]
2014-07-17 21:28 ` Theodore Ts'o
2014-07-17 21:37 ` Andy Lutomirski
2014-07-17 22:21 ` David Lang
-- strict thread matches above, loose matches on Subject: below --
2014-07-20 16:26 George Spelvin
2014-07-20 17:03 ` George Spelvin
2014-07-20 21:32 ` Hannes Frederic Sowa
2014-07-21 11:21 ` George Spelvin
2014-07-21 15:27 ` Hannes Frederic Sowa
2014-07-22 1:02 ` Hannes Frederic Sowa
2014-07-22 4:44 ` Theodore Ts'o
2014-07-22 9:49 ` Hannes Frederic Sowa
2014-07-22 22:59 ` Theodore Ts'o
2014-07-23 9:47 ` Hannes Frederic Sowa
2014-07-23 11:52 ` George Spelvin
2014-07-23 12:10 ` Hannes Frederic Sowa
2014-07-30 12:50 ` Pavel Machek
2014-07-20 17:24 ` Theodore Ts'o
2014-07-17 9:18 Theodore Ts'o
2014-07-17 10:57 ` Hannes Frederic Sowa
2014-07-17 12:52 ` Theodore Ts'o
2014-07-17 13:15 ` Hannes Frederic Sowa
2014-07-17 12:09 ` Tobias Klauser
2014-07-17 12:52 ` Theodore Ts'o
2014-07-17 16:12 ` Christoph Hellwig
2014-07-17 17:01 ` Theodore Ts'o
2014-07-17 17:05 ` Bob Beck
2014-07-17 17:34 ` Theodore Ts'o
2014-07-17 17:45 ` Bob Beck
2014-07-17 17:46 ` Bob Beck
2014-07-17 17:57 ` Bob Beck
2014-07-17 22:30 ` Theodore Ts'o
2014-07-17 19:56 ` Bob Beck
[not found] ` <CAComcpObt4y--GEuAZgzkaDWnrJYBKhwsvqjOkdiXU_yGnV2Tg@mail.gmail.com>
[not found] ` <CAComcpObt4y--GEuAZgzkaDWnrJYBKhwsvqjOkdiXU_yGnV2Tg-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2014-07-17 20:43 ` Theodore Ts'o
[not found] ` <20140717204340.GS1491-AKGzg7BKzIDYtjvyW6yDsg@public.gmane.org>
2014-07-17 21:44 ` Zach Brown
[not found] ` <20140717214450.GE24196-fypN+1c5dIyjpB87vu3CluTW4wlIGRCZ@public.gmane.org>
2014-07-17 22:00 ` Andy Lutomirski
[not found] ` <CALCETrVC2SVC2BwintZ7P5MvwDO4z0VBe0svpWhVhx7Xgfoeag-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2014-07-17 22:27 ` Theodore Ts'o
2014-07-21 0:25 ` Dwayne Litzenberger
2014-07-21 7:18 ` Theodore Ts'o
2014-07-17 19:31 ` Greg KH
2014-07-17 19:33 ` Greg KH
2014-07-17 19:48 ` Zach Brown
[not found] ` <20140717194812.GC24196-fypN+1c5dIyjpB87vu3CluTW4wlIGRCZ@public.gmane.org>
2014-07-17 20:54 ` Theodore Ts'o
2014-07-17 20:54 ` Theodore Ts'o
[not found] ` <20140717205417.GT1491-AKGzg7BKzIDYtjvyW6yDsg@public.gmane.org>
2014-07-17 21:39 ` Zach Brown
2014-07-17 21:39 ` Zach Brown
2014-07-17 20:27 ` Andy Lutomirski
[not found] ` <53C8319A.8090108-kltTT9wpgjJwATOyAt5JVQ@public.gmane.org>
2014-07-17 21:14 ` Theodore Ts'o
2014-07-17 21:14 ` Theodore Ts'o
2014-07-18 16:36 ` Rolf Eike Beer
2014-07-20 15:50 ` Andi Kleen
2014-07-20 17:06 ` Theodore Ts'o
2014-07-20 17:27 ` Andreas Schwab
2014-07-20 17:41 ` Theodore Ts'o
2014-07-21 6:18 ` Dwayne Litzenberger
2014-07-23 8:42 ` Manuel Schölling
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=53C83383.4040507@amacapital.net \
--to=luto@amacapital.net \
--cc=beck@openbsd.org \
--cc=linux-crypto@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mark.kettenis@xs4all.nl \
--cc=tytso@mit.edu \
/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: link
Be 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.