From: Theodore Ts'o <tytso@mit.edu>
To: Nikos Mavrogiannopoulos <nmav@gnutls.org>
Cc: Stephan Mueller <smueller@chronox.de>,
Herbert Xu <herbert@gondor.apana.org.au>,
Linux Crypto Mailing List <linux-crypto@vger.kernel.org>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
Sandy Harris <sandyinchina@gmail.com>
Subject: Re: [RFC][PATCH 0/6] /dev/random - a new approach
Date: Mon, 25 Apr 2016 21:11:37 -0400 [thread overview]
Message-ID: <20160426011137.GC28496@thunk.org> (raw)
In-Reply-To: <CAJU7zaL+jYCgq0RzSraCQF6hd6QtxhobkPtxt+_YqxiZ+vfkMw@mail.gmail.com>
On Mon, Apr 25, 2016 at 10:23:51AM +0200, Nikos Mavrogiannopoulos wrote:
> That's far from a solution and I wouldn't recommend to anyone doing
> that. We cannot expect each and every program to do glibc's job. The
> purpose of a system call like getrandom is to simplify the complex use
> of /dev/urandom and eliminate it, not to make code handling randomness
> in applications even worse.
Yes, but if glibc is falling down on the job and refusing to export
the system call (I think for political reasons; it's a Linux-only
interface, so Hurd wouldn't have it), then the only solution is to
either use syscall directly (it's not hard for getrandom, since we're
not using 64-bit arguments which gets tricky for some architectures),
or as Peter Avin has suggested, maybe kernel developers will have to
start releasing the libinux library, and then teaching application
authors to add -linux to their linker lines.
- Ted
next prev parent reply other threads:[~2016-04-26 1:11 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-04-21 9:11 [RFC][PATCH 0/6] /dev/random - a new approach Stephan Mueller
2016-04-21 9:12 ` [PATCH 1/6] crypto: DRBG - externalize DRBG functions for LRNG Stephan Mueller
2016-04-21 9:13 ` [PATCH 2/6] random: conditionally compile code depending on LRNG Stephan Mueller
2016-04-21 9:13 ` [PATCH 3/6] crypto: Linux Random Number Generator Stephan Mueller
2016-04-21 9:14 ` [PATCH 4/6] crypto: LRNG - enable compile Stephan Mueller
2016-04-21 9:14 ` [PATCH 5/6] crypto: LRNG - hook LRNG into interrupt handler Stephan Mueller
2016-04-21 9:16 ` [PATCH 6/6] hyperv IRQ handler: trigger LRNG Stephan Mueller
2016-04-21 13:03 ` [RFC][PATCH 0/6] /dev/random - a new approach Nikos Mavrogiannopoulos
2016-04-21 13:09 ` Stephan Mueller
2016-04-21 15:16 ` Stephan Mueller
2016-04-25 7:55 ` Nikos Mavrogiannopoulos
2016-04-25 8:02 ` Stephan Mueller
2016-04-25 8:23 ` Nikos Mavrogiannopoulos
2016-04-26 1:11 ` Theodore Ts'o [this message]
2016-05-03 13:57 ` Nikos Mavrogiannopoulos
2016-05-03 14:48 ` tytso
2016-05-03 16:20 ` Nikos Mavrogiannopoulos
2016-05-03 15:01 ` Austin S. Hemmelgarn
2016-04-22 2:51 ` Theodore Ts'o
2016-04-22 4:59 ` Stephan Mueller
2016-04-22 13:09 ` Sandy Harris
2016-04-24 15:21 ` Pavel Machek
2016-04-24 17:32 ` Stephan Mueller
2016-04-24 21:25 ` Pavel Machek
2016-04-25 5:12 ` Stephan Mueller
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=20160426011137.GC28496@thunk.org \
--to=tytso@mit.edu \
--cc=herbert@gondor.apana.org.au \
--cc=linux-crypto@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=nmav@gnutls.org \
--cc=sandyinchina@gmail.com \
--cc=smueller@chronox.de \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).